A better way to think about tests
Tests are awesome, but not a lot of people want to write them(myself included at times). This is just a rant type blog and I am probably being really dumb, but I had to get this out there.
I just wanted to talk about how we introduce beginners to the idea of writing tests. When I started off my career, I was told that tests were a way for one to catch bugs in one's code. Even now, in most cases that is how a lot of beginners are being introduced to the idea of writing tests. When we do this, tests comes out as thing that you don't really have to do if you are writing proper code and also as something that will only benefit you in the future. That I think is the main reason why a lot of people don't write tests, because we all know that we write bug free code.
What I suggest instead is to introduce writing tests as a way for you to automate checking if what you wrote is correct. Well, it might seems as if I just reorderd the words. Let me explain.
Let me walk you through a situation. Let us say that every time you make a change, there is a "all knowing" senior dev sitting beside you, looking at your code and telling you if you mess something up and telling you where you messed it up. That would be great, right? Tests are a similar thing, or at least they can be. It is something that you can have constantly running on your code and letting you know if you made a mistake. When you think about it this way, TDD starts to make a lot more sense.
We should not treat tests as something that can help you catch bugs in the future, but rather something that will help you automate how to check if what you wrote actually makes sense as you write it.
Think about it this way. It does not matter if you are writing tests or not; if you are a sane developer, you will most probably try and run the piece of code that you just wrote to see if it does the thing that you think it should do. Why not automate that? That is what tests are for, not just to catch bugs in future. I know a lot of people who write tests just so that they can get the CI to pass, but it should be something that you want to write and not something that you have to write.
Btw, not only will the "all knowing" senior dev help you with issues in your code, they can even help other people with issues in their code if you have a good CI setup.
All of this only works if you have a good workflow for running tests in the first place
Tests should not be something that you treat as something that have to do before you push upstream, but rather something that will actively helps you throughout the process of adding in a feature.
So, to sum it all up, here is how I would introduce someone to testing. You write tests so that you can automate checking if what you wrote works. Once you write a piece of code, you should be able to asks the tests to checked if what you wrote is correct. If you write a really broad test, it will help you to fine out that there is an issue, but if you write more find grained tests, it can tell you where exactly things are going wrong.
These kind of tests, along with the regression tests one accumulates over the years should be enough to build out your "all knowing" senior dev for the most part.
Again, I really wanted to stress on the importance of having a really good workflow. If running tests are gonna be harder than or as hard as just running the thing the thing and seeing if it works, my point becomes moot.
That is it for today. Thanks for reading.