While constantly updating your scripts is not necessarily a bad thing

having your tests break every time there is a new release of code is a bad thing. If your tests continually stop working for no good reason, people are going to stop trusting them. When they see a failing build they will assume that it's another problem with the tests, and not

an issue with the website you are testing.

So we need to nd a way to stop our tests from failing all of the time for no good reason. Let's start off with something easy that shouldn't be too controversial; let's make sure that the test code always lives in the same code repository as the application code.

How does this help?

Well, if the test code lives in the same repository as the application code it is accessible to all the developers. In the previous chapter, we had a look at how we could make it really easy for developers to just check out our tests and run them.
If we make sure that our test code is in the same code base as the application code, we have also ensured that any developers who are working on the application will automatically have a copy of our tests. This means that all you have to do now is give your developers a command to run and then they can run the tests themselves against their local copy of code and see if any break.

Another advantage of having your test code in the same repository as the application code is that developers have full access to it. They can see how things work, and they can change the tests as they change the functionality of the application. The ideal scenario is that every change made to the system by developers also results in a change to the tests to keep them in sync. This way, the tests don't start failing for no real reason when the next application release happens and your tests become something more than an automated regression check; they become living documentation that describes how the application works.