[bazza451]

Testing is valuable but my opinion of it has changed over the years.

On a new/fast evolving product I prefer to have a solid suite of integration/e2e tests and a lighter unit test suite near the edge of a server with no mocking of deps (e.g. if it uses a db, spin up a local instance). I would also test something that is non-trivial to understand or a critical dependency in the system e.g. a rules engine.

The reason being is - the code is in so much flux that the internal interfaces change constantly. In agile new requirements come along and you end up chucking a lot of the old code out of the window and wasting time.

As you move towards completion of the project and the internal interfaces shore up then increase the tests. So when it’s in maintenance mode someone else can easily make modifications and has documentation on maybe why something works in a certain way

[gt565k]

Couldn't have said it better myself. Overzealous testing while building an MVP for a project is just a waste of time as the code gets thrown out and redone so many times before it gets to the end user.

On the other hand, if requirements are mostly defined from a UX/UI workflow and and business logic perspective, that's a whole other story. Then it's easy to justify testing everything, as the expectation that the requirements will change is fairly low. Unfortunately, most companies don't follow the correct way of building software because it requires extra upfront time and resources.

[codextremist]

I couldn't agree more. Over the last 5 years I've changed the way I think about testing. Why would u bother about testing in the beginning when your product is constantly evolving? Also, a senior and organized team helps a lot in this process. I'm currently working with two senior developers and we feel that testing can still be postponed safely until we grow our team or our product becomes more mature and interfaces gets more solid and well defined. Nowadays these are my golden rules for testing a small size project/product:

1 - e2e tests for flows and interfaces that are less likely to change.

2 - write unit tests for core models that are specially difficult to test e2e or core models with complex business rules (if it's a backend code, usually your db table with the highest number of relations)

[thiago_fm]

e2e is definitely a thing, but I wouldn't leave unit testing aside. For bigger applications, it makes it impossible to write an e2e for everything. But I get your point, we must definitely be smart about the testing we write and why.

[PeterisP]

Unit testing makes sense when there are some units for which you can define correct behavior. E.g. you may not know all the requirements yet but if you can isolate some components that you're going to definitely need, then you can write unit tests for them. While you're still iterating about what that unit is going to do (and whether you'll have that unit at all) unit tests make little sense.

However, in quite a lot of common scenarios, e.g. a simple user-facing CRUD webapp, none of the custom content functionality is expected to be stable enough, it's all still in flux (and thus any unit tests would have to change at every iteration); and all the components where from the beginning it's clear how they should work (e.g. user authentication, sending of email notifications, etc) aren't really custom, so they're already written and tested, you're going to simply use them from your framework or standard libraries.

[glun]

1000x this.

[qualsiasi]

I totally agree