The benefits of religiously following a strict Test Driven Development (TDD) approach (always write tests first before code) is a hotly debated topic. No experienced developer would ignore the fact that testing is essential, but there are debatable pros and cons for whether writing unit tests before, during or after has the most benefit.
If your team has a commitment to unit testing there is valuable side benefit to your code quality that can arise by itself but is usually encouraged by more experienced development teams. Overly complex code that doesn’t have a clear or single responsibility, is tightly coupled with other code and/of is excessively long, is hard to test. Complex code is hard to understand and maintain, it’s usually also the source for more defects compared with simpler and easier to understand code. Effective teams always look for areas where they can become more efficient and make their lives easier, and aiming to develop simpler code to make it easier to test brings these additional benefits with it.
By adopting a mindset that code should be developed and structured in a simpler way so that it is easier to test, you instantly gain from the benefits of simpler code that’s easier to maintain. Win-win all round.
Unit testing is fine for things like sorting, or consumer apps. But it does not work at all for scientific apps (e.g., 3-D MHD codes or turbulence) because the “right” answer is unknown. There is no way to test the code except by using it and then using scvientific judgement to determine if the answer is correct.
If by scientific judgement you can determine whether the output is “correct” then you can still write a unit test to test the code is producing that expected output. This way you still get many of the additional benefits from unit testing – automated test suites, CI/CD go/no go code quality gates, regression test suites etc