I just want to preface this post with saying that this whole post is just my experience and will give you no practical advice or opinions.
4 Years Ago I Could Not Assert 2 + 2 = 4
Four years ago when I was 20 years old I was given my first software development job. Not only was this my first big job but it was at a fortune 500 company where I was surrounded by experts so I never felt like I really knew anything in comparison. Luckily for me these experts were amazing mentors and I owe most of what I know to these people, BUT this didn't stop me from always feeling like I didn't know enough. I remember the first time one of the senior devs paired with me and showed me his tests It felt like this already massive amount of knowledge I was lacking tripled in size. I had a lot of questions
- Why write tests? They seem like they take a long time.
- How do you know what to test?
- What in god's name is a mock or a stub?
- Why would I need to mock something, doesn't that defeat the purpose of a test?
- What is the difference between unit, behavior, and integration tests?
- What is black/white box testing?
- Now I'm testing a react component, is it inappropriate to simulate a click event in a unit test?
- I'm scared I will spend all this time writing tests that no one will run except me, should I still write them?
This list could go on forever really. The idea of writing tests seemed so foreign, I mean I was still learning how to write code, I didn't have time to learn this nuance that is testing.
3 Years Ago I Avoided Tests Like the Plague
Having spent many hours of many days trying to learn how to write tests I concluded that testing was not for me and that it slowed down the software development process too much to be valuable. My team didn't have any hard requirements like the code must have 70% test coverage or anything silly like that so it was fairly easy to avoid. Although I was happy avoiding testing I couldn't help but feel that every time QA would find a bug that maybe I could have avoided that bug if I had written tests. It was worse when something I knew to be working before would get a bug filed a couple months down the road saying it no longer worked. It felt like I would write a feature and break 2 others, and I wouldn't know it until QA or a user would tell me about it. Having broken many things I really started to fear making changes. Not feeling confident in my code was and is the worst feeling in software I have had.
2 Years Ago I Wrote Tests But They Sucked
I had come a long way in my journey to learn how to test. Let me try and rephrase that... I had come a long way in my journey to write tests that were fragile. I was no longer scared to write tests, especially unit tests. I knew how mocks worked and I would mock anything in the world if it meant I could isolate my test in it's own little tiny sandbox. My solution was to unit test everything in order to conquer my fear of making changes. This led to me wasting a lot of time refactoring tests over and over because an implementation would change and all of a sudden I had to change 6 test files because they relied on that implementation. My productivity was at an all time low, even though I was writing more tests and having less bugs, but there had to be a better way.
1 Year Ago I Stopped Having Hard Opinions And My Life Was Blissful
I had given up on the idea that everything needed to be unit tested. In fact my opinions were quite the opposite, and instead I looked for the right test for the job. There was no need to unit test a controller that relied on 8 other classes to be injected in the constructor, this would only lead to a fragile test, instead this would be better suited for an integration test. I was beginning to instinctively understand what kind of tests would be most appropriate.
0 Years Ago (Today 😉)
I teach other developers how to test, and I feel extremely confident in the tests that I write. My tests rarely break for the wrong reasons, and I spend more time developing than worrying about how I'm going to test this feature. My biggest problem is implementing build systems that make sure tests pass before code is merged.
I wrote this article because I want junior developers to know that your not alone if you find testing difficult for a long time. Software development is hard and anyone that says otherwise is either a genius or naive (most likely the latter.) It doesn't help that everyone has their own opinions when it comes to testing and it seems that every article you read contradicts the last article. Just know that your not alone if you feel this way, and you will one day conquer those tests and feel proud!
Maybe one day I'll write about my own opinions when it comes to testing.
Top comments (1)
Love this sentiment, I feel like it's too easy to forget that testing is all about increasing confidence in your code. Tests that don't do this are worse than no tests since they increase brittleness without providing value. It seems to me like tutorials on unit tests tend to mock/stub too readily, tutorials on integration tests are few and far between, integration tests are difficult to write and maintain, and integration testing tools (at least for JS) are generally still pretty fragmented and immature.
In short, I totally agree that it's very difficult especially for junior devs to learn how to test properly and to discover the value of testing – thanks for writing this post, looking forward to reading more of your thoughts on it!