This is the traditional approach, focusing on problem-solving code rather than tests. Some people and companies forget about the value of automated testing and rely on users in what are called user acceptance tests.

This kind of user acceptance test consists of recreating real-world scenarios in a controlled environment, ideally identical to production. Some users perform a lot of different tasks to verify the correctness of the application. If any of these actions fail, then the code is not accepted, as it is breaking some functionality or it is not working as expected.

Moreover, a great number of these companies also use unit testing as a way to perform early regression checks. These unit tests are created after the development process and they try to cover as much code as possible. Last of all, code coverage analysis is executed to get a trace of what is actually covered by those unit tests. These companies follow a single rule of thumb: the bigger the code coverage, the better the quality delivered.

The main problem of this approach is that writing tests afterwards does nothing but demonstrates that the code behaves the way it has been programmed, which is not necessarily the way code is expected to behave. Also, focusing on code coverage leads to bad tests that turn our production code into immutable entities. Every modification we may want to add may cause several tests from different, unrelated parts of the code to fail. That fact means the cost of introducing changes becomes really high and performing any slight modification could end up being a nightmare and very expensive.

To demonstrate some points described earlier, let's implement the Connect 4 game using a TDD and not-TDD approach. The relevant code for each of the identified requirements is presented as we proceed further. This code isn't written incrementally, so some code snippets might contain a few code lines unrelated to the mentioned requirement.