Testing is an oft argued topic, as I discovered when I started at
Readify.
As a bit of a testing noob, I’d only read a bit about testing and thought “That sounds useful, more things caught before deployment”, but upon trying to write them, I found it hard to come up with sensible scenarios. Many of the tutorials I’d seen were around calculations which just aren’t a part of my job in any way.
This was likely due to my lack of knowledge around programming at the time (if not still) and lack of imagination. Reading through some of the tests in my projects I often pondered the point of them. I’m always adjusting them to fit the code, but not in a useful way. They didn’t so much test scenario as tell me when I changed a scenario, which isn’t necessarily a bad thing, but wasn’t the point of that test.
My colleague
Andrew Best linked me an
NDC talk about testing which was quite informative.
The big takeaway I got from it was that tests should be:
These stuck with me because I’d been reading through the tests on one project which was testing a mapper. At one point, perhaps these tests were useful (the mapper did more than basic mapping in the past), but now it was just testing that values got assigned to variables.
Chatting with workmates on the subject, they pointed out that this could still add value by picking up when a mapping was deleted or something but agreed that it was a fairly low value test and should be tested at a higher level.
The video asserts that the point of testing is to allow you to gain enough confidence to release to production.
As I read through existing tests and go to write new tests, I’ll have my testing glasses on a bit more and see the tests that add value and the tests that are a bit heavier than they need to be.
