Writing tests is something that I think a lot of developers come to later on. It's quite often that when developers are learning to code, whether that is self taught, through bootcamps or at university; testing is often overlooked.
I don't get it, why is testing not focused on enough? When you start working on production projects and in teams you often find that testing is something you simply have to do.
I think part of it comes down to the case for writing tests not being clear enough. It's like the developers version of office paperwork - nobody seems to want to do it. Let me go through why you should be writing automated tests.
In most workplaces, a typical scenario is this. You're working on a REST endpoint for an API. It starts off fairly simple but over time it gets more and more complicated. Before long you are using repositories, caching and the whole thing becomes a bit daunting to touch. Because you become worried about breaking things you don't refactor the code and over time it becomes this spaghetti code that people don't want to work with.
Testing makes this better.
Put simply, automated testing is making sure that your code does what it is supposed to do. You interact with your API you have created and assert that the correct actions have occurred. Whether that is a HTTP response code, checking that a record exists in the database or just something else.
It's also worth mentioning that testing is not a magic bullet. It follows the same principles as most things GiGo (Garbage in, Garbage out). You have to make sure that the tests you write are meaningful and useful otherwise they serve no purpose.
So I have already covered a couple of reasons why automated tests are useful. But let me dive in a little deeper on why you should be writing automated tests.
As I mentioned above, it doesn't take long to create these large classes that are unwieldy. One of the best benefits that testing gives you is this confidence as a developer. You can make any change you want, simply run the test suite and know straight away if you have broken anything.
This gives you a lot of flexibility. You can not only refactor code worry-free, but you can also experiment with solutions without the fear of breaking the code.
Testing often requires you to think from a different perspective. You have to take your developer hat off and put on your consumer hat. Whether this is how someone will consume a HTTP API or a package, you can design your system in a way that is best for the consumer.
Because of this, it allows you to easily think of edge cases in how the user might choose to interact with your application. How many times have users used an app in a way you hadn't anticipated?
Contrary to what a lot of people think, testing does save you time. How can this be when you are writing the test as well as the implementation you ask? Well because it allows you to spot bugs easier you are less likely to spend time debugging for a start. If a bug gets reported in your system, write a test to reproduce the bug and then you can interact with the application in isolation to find the root cause.
Testing is something that you are spending time writing as an investment in the future.
Generally speaking no. But remember this is not a law, use your best judgement. If you are writing a small app just to play around with an idea and you are not planning on releasing it to the outside world then there is no harm in not writing any tests. That being said, it is a really good habit to get into and the more you do it the easier it will become.