I recently shared a video where I showed how Copilot Chat can write tests for you, a funny demo, but today's article will not be about AI. The thing is, it should not be a matter of time.
If you ship some code, you should consider automated tests as an actual part of the code. You wouldn't deliver half a feature, right?
Something that usually helps me put it in perspective in case a client or a project manager is not convinced is to try to visualize that tests are not necessarily something for today, but rather for tomorrow.
Let's make it simple, spending 20% more time today to save 80% of the time tomorrow should sound like a good deal.
But we can't! Today we're in a hurry!
Ok cool, we can save 20% of time today... but what if we'll be in a hurry again tomorrow? Technical debt is a thing.
Pros & Cons
I mean, writing tests is hard, and that's why it takes time. However, the more you write tests, the better and more testable will be your code, and the less time you'll spend the next time!
On this topic I recorded a video where I go through some pros and cons, in particular:
Pros
- Find bugs early - no need to explain this one, rather than finding a bug in production, you find it while writing the code
- Tests are like documentation - if you're new to the project and you look at the test descriptions, you immediately get some insights into what some code does
- Fewer bugs on changes - everytime you change something you might break something else, tests will tell you if you did, as long as they're good ones
- Save time - as mentioned above, you'll spend more time today, but you'll save a lot of time tomorrow, in particular when a bug is found in production
- Write better code - this is a really convenient side effect, writing tests will actually force you to write better code, more modular and readable
Cons
- Being overconfident - if you have 100% code coverage, you might think that your code is perfect, but that's not true. What about edge cases? Are those covered?
- Maintenance cost - tests are code, and as such they need to be maintained. If you change something in the code, you might need to change the tests as well
- Longer builds - if you have a lot of tests, your build will take longer. There are indeed some optimization, but at some point your tests will have to run
- Wrong usage of Code Coverage - code coverage is a metric, and as such it can be used in the wrong way. If you have 100% code coverage, it doesn't mean that your code is perfect, it just means that all the lines are executed at least once. You might have a lot of tests, but if they're not testing the right things, you're not really testing anything... I mean, once again I recorded an entire video on this topic, you can find it here
This was just a highlight of what the video will be about, if you're interested in hearing about my take, you can watch it here:
Thanks for reading this article, I hope you found it interesting!
I recently launched my Discord server to talk about Open Source and Web Development, feel free to join: https://discord.gg/bqwyEa6We6
Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:
Feel free to follow me to get notified when new articles are out ;)
Top comments (5)
When contacting, i usually make sure to have a clause that say "development will be done according to best practise of the industry" and if asked to skip some part later, i just get back to this clause to justify it. All of the above argument are still good to explain it, but any argument are avoided since it's in the contract.
You might argue on what "best practice of the industry" means but indeed mentioning something in the contract is a smart move :D
Pretty sure we cannot find a source that say not to do tests.
But yes it has to be adapted, most of the time I work with company without IT team and like to keep it simple, although maybe vague.
But I'm one case (subcontracted from an agency) we were a team of contractor that had to include a few developer from the customer so they could take over once the bulk of the project was completed. In that contract, the whole process including detail on scrum and testing practice were detailed.
That doesn't need necessary to me.
If the client needs to work with you, it doesn't need to be convinced by how you work. Writing tests is your responsability, just like managing dependencies etc. Your client don't need to be convinced or even care that you need to pick the right libraries and udpate them.
With a client you need to have a WHY? conversation
Use that to define what OUTCOMES he needs.
But the HOW? is entirely up to you.
You are the expert. Don't ask for permission.
Great points made.
One additional Pro I've found when writing tests is that it makes you think in depth about the different paths that the logic can go. As a result, it sometimes leads me to cater for a few more edge cases than I would have otherwise.