Test-driven development approach

You will often hear about the test-driven development (TDD) approach, which basically means writing tests first. To simplify this, let's summarize this in the following three steps:

1. Write tests and watch them fail.
2. Implement functionality until you see your tests passing.
3. Refactor to the best practices (optional).

I must admit that I really love this approach. However, the truth is that most developers will glorify this approach and barely any will use it. This is usually because it's time-consuming and it is hard to predict what the thing you are about to test looks like.

Going further, you will find that one of the test types is against TDD. Snapshot tests can only be created if the component is implemented, as they rely on its structure. This is another reason why snapshot tests are more of an addition to your tests rather than a replacement.

This approach works best in huge applications that go on for years, where a team of tech architects plan the interfaces and patterns to be used. This is most likely in backend projects, and you will have a general idea of how all of the classes and patterns connect to each other. Then, you simply take the interface and write the tests. Next, you follow up with implementation. If you want to create interfaces in React Native, you will need to support TypeScript.

Some argue that TDD is great in small projects, and you may quickly find such threads on Stack Overflow. Don't get me wrong; I'm happy that some people are happy. However, small projects tend to be very unstable and are likely to change often. If you are building a Minimum Viable Product (MVP), it doesn't work very well with TDD. You are better off relying on the fact that the libraries you use are well-tested and deliver the project on time, while quickly testing it with snapshots.

To summarize: abandoning TDD should not mean writing less tests.