Are you expecting a developer to test everything every time they commit? Thoroughly testing even a small application or feature subset will take up quite a bit of time. You also want devs to commit often, so it is easy to roll back an approach that didn’t pan out, or just to go back and figure out what change caused something to stop working. If you end up committing only a few times per week because everything needs to be thoroughly tested, I’m not convinced it is a good approach.
No, they should not need to test everything, but this strongly depends on your code quality and project setup.
There’s definitely other paths to the goal, but generally for larger projects, I recommend:
Good isolation between components. A change in one component should not have unforeseeable effects in other components.
Automatic unit tests for each component, so devs can test their changes in isolation.
A statically typed, compiled language, so that compiling does a basic integration check between components.
Strong ties between components, where it makes sense. For example, ideally, the communication model between backend and frontend is in a shared module/library, so that if someone does change the model, it leads to compile errors on both sides.
Automatic integration tests + a CI/CD pipeline, which tests the rest of the application after each push. This will let you know as early as possible, if you did push a broken commit.
A multi-project build with all parts of your application in a monolithic repo, so that all components get continuously compiled + integrated with their most recent changes.
This rigidity does have challenges of its own.
For example, a change in the backend might force a change in the communication model and therefore in the frontend, too. And if you’re exclusively backend, you might struggle with updating the frontend accordingly.
Then you’ll need to push onto a separate branch and look at it with your frontend colleague later. But hopefully, you get that arranged within a day or two, so the merge conflicts should still be quite tame.
And obviously, this rigidity has tons of advantages. Not needing to wonder whether frontend and backend, or any other interface, is compatible right now, is just insanely good.
Are you expecting a developer to test everything every time they commit? Thoroughly testing even a small application or feature subset will take up quite a bit of time. You also want devs to commit often, so it is easy to roll back an approach that didn’t pan out, or just to go back and figure out what change caused something to stop working. If you end up committing only a few times per week because everything needs to be thoroughly tested, I’m not convinced it is a good approach.
No, they should not need to test everything, but this strongly depends on your code quality and project setup.
There’s definitely other paths to the goal, but generally for larger projects, I recommend:
Good isolation between components. A change in one component should not have unforeseeable effects in other components.
Automatic unit tests for each component, so devs can test their changes in isolation.
A statically typed, compiled language, so that compiling does a basic integration check between components.
Strong ties between components, where it makes sense. For example, ideally, the communication model between backend and frontend is in a shared module/library, so that if someone does change the model, it leads to compile errors on both sides.
Automatic integration tests + a CI/CD pipeline, which tests the rest of the application after each push. This will let you know as early as possible, if you did push a broken commit.
A multi-project build with all parts of your application in a monolithic repo, so that all components get continuously compiled + integrated with their most recent changes.
This rigidity does have challenges of its own.
For example, a change in the backend might force a change in the communication model and therefore in the frontend, too. And if you’re exclusively backend, you might struggle with updating the frontend accordingly.
Then you’ll need to push onto a separate branch and look at it with your frontend colleague later. But hopefully, you get that arranged within a day or two, so the merge conflicts should still be quite tame.
And obviously, this rigidity has tons of advantages. Not needing to wonder whether frontend and backend, or any other interface, is compatible right now, is just insanely good.