Like many programmers, I learnt to test the hard way. That is, I didn’t test when I started coding, and my first big app grew into a monster that I grew to fear changing because I wasn’t sure of the consequences. This has greatly influenced why I test:
I test so that I can safely and confidently refactor
I am a firm believer in the mantra that code should improve every time you touch it. The only way that can happen, is if you can refactor at any stage of the development cycle. That can only happen if you have a set of tests that you know work.
There are other reasons I test, but these are minor to the “refactor reason”.
I tend to think in the test space. That is, when I’m thinking about how I want an object to behave I’ll will create a test that relies on the object working in a particular way. Then I build the object to satisfy the test.
I have worked on projects where requirements were passed to the development team in the form of cucumber type scenarios. I think this is an excellent way to work but it only works if the project manager/internal customers buy into it and actively uses it. This has only happened in about 10% of the projects I’ve worked on. In my opinion, if you don’t have that buy in, you’re just adding extra complication for no benefit - and as a firm believer in KISS complication that doesn’t add value, doesn’t belong in any development.
I’ve gotten pretty good at building a big monolith of an application on my own solo projects and doing so with only self testing. I have changed into writing Minitest tests because understanding and knowing the monolith is easy until you delete huge parts of it. Then the mental image of it becomes clouded and confusing. My mind is an excellent state machine, but deleting code changes that in a not-so-easy to recall way. Tests help me narrow down the current implementation, or at least allow me to have a nice snapshot of the bigger picture.
I should mention I’m not that many years into testing. So I am rather young as a TDDer. While learning Rust I TDD everything. I need to verify what’s going on each step of the way here to truly know what I know.
My biggest app is actually my first app… and there’s no tests
Having said that, it’s also my best app - I’ve got another three Rails apps and, because I needed them up quickly, they were real quick n dirty jobs.
I also think it helps that I had just read a tonne of books before starting my first app, all the best practises, tips n tricks were fresh in my mind and it shows in the app tbh - it’s definitely the one I am most proud of.
I had actually read The RSpec book (great book) but I was eager to work on (just) the app itself and not get bogged down by testing. I was also undecided whether to go with RSpec or not.
I think a useful way of thinking of tests is as a record of your “self tests” written in away that they can be run again as and when you need to test functionality. If you think of them that way you’ll find they will grow as your app grows.
