A good design is going to provide more value over time than a good test suite. A lot of developers spend a lot of time writing tests for terrible design on prototype codebases. Those prototypes eventually are thrown into production full of bugs and the answer tends towards "more tests!" instead of "better design!"
Most developers just keep building on top of the same codebase until it is a total mess, long after the team has learned a bunch and should refactor or throw away the code and build something designed for production use.
There is really not enough discussion about when he right time to do thorough testing and when a project transitions from prototype to production quality.
I realize things like software design, planning, and thoughtfulness are heresy in the agile world of 2 week sprints, but most of these things are our own fault due to a lack of planning and craftsmanship. Complain all you want, but in general it's our own fault.
100% agree. The problem is # of tests and test coverage are measureable. Good design isn't (at least not in the short term). There is something to the argument that thinking about testability helps with design but in practice this often does not help.
Yet another problem is there is never time to throw away and build something new. In the life-cycle of most companies/products the available time decreases as a function of time since now you have customers, you have bugs, you have a fatter organization to feed, etc. The time to get the design right is the beginning and you have to do that fairly quickly...
> Most developers just keep building on top of the same codebase until it is a total mess, long after the team has learned a bunch and should refactor or throw away the code and build something designed for production use.
That's exactly where a good test suite comes to save you. If you have tests you can refactor as much as you want until you get the code you want. If you don't you will never have enough time to refactor the code base because the effort of manually testing will be too high. And as result your code will rot over time.
Yes, but if you are leaning on your test suite to verify a huge refactor, you are unlikely to make the kind of sweeping design changes that are sometimes needed.
For example, say your ORM is causing major trouble and you need to replace everything from the controller back to the database. Heck, maybe you decouple the whole backend out into an API. The only tests that help you are the end to end tests. The rest of your test suite for your backend needs to be thrown away as much as your backend itself does.
More often than not the unit tests will have assumptions about the design in them so they will actually stand in the way of refactoring rather than facilitate it. If you have class A with unit tests this is basically a design decision reflected right there. If having class A is bad design fixing that requires dealing with tests + class A and the tests are a hindrance rather than help.
Most developers just keep building on top of the same codebase until it is a total mess, long after the team has learned a bunch and should refactor or throw away the code and build something designed for production use.
There is really not enough discussion about when he right time to do thorough testing and when a project transitions from prototype to production quality.
I realize things like software design, planning, and thoughtfulness are heresy in the agile world of 2 week sprints, but most of these things are our own fault due to a lack of planning and craftsmanship. Complain all you want, but in general it's our own fault.