Testing and the False Economy

I hear a lot lately (on the nerd vine) that testing is a luxury.

I always though this came from the mouths of the lazy and the managers, but apparently not. A lot of people seem to feel that testing isn't necessary to ship an MVP product- if you write good code that is clean and readable there shouldn't be bugs that aren't obvious and there isn't time to add tests on a tight deadline. I've even heard this in interviews.

I don't agree and I hate this way of thinking but I can kind of understand where they're coming from - if the deadline is tight how can you justify spending hours on tests? I would say the cliche answer - add tests now and save time later or you buy into the false economy - shame it doesn't work on people.

There's nothing I can say that these people haven't heard - and actually maybe they're right. I can't say for sure that I know best when I'm hearing different from people with decades more experience - but lets put a pin in this and think about where testing fits in with SOLID and how you can mitigate the risk of spending ages on tests amd being bored silly, only for them to all be broken tomorrow because your colleague doesn't bother to run them before a merge (something that drives me mental).

I dont want to talk about all of SOLID (there's plenty of that out there) but the O stands for the "Open for extension / Closed for modification" principle and it seems to me that tests and O/C are made to solve this problem and help convince the undesirables to start testing properly.

Open for extension essentially means that your class or service should be open for new features but at the same time closed for modification of existing features (isn't always possible IMO). If you do your best to follow that, and get buy-in from your team, it seems to me that you will naturally end up with small chunks of functionality that you slowly reuse and compose larger chunks with. Those chunks shouldn't be changing so surely their tests shouldn't either? If that's true your tests wont break tomorrow and you can stroll gloriously into the office without an immediate headache.

Of course this isn't the only argument for finding time for tests - but its one I haven't thought about before. I hope this will make you think about writing testable code in a new way and about new ways we can convince our overlords that &%(*!!ing bricks on release day is probably not the way forward.