127 likes
·
1.8K reads
18 comments
This is a terrific article! I like the writing style and the content.
Honestly I need to establish a better unit testing habit. I don't unit test my personal projects often because TDD feels foreign.
Which also leads me to ask, did TDD feel foreign to you at first?
If so, how did you adapt?
Thanks for your kind words Darren! 🙏
Be careful with TDD. Let me explain. It is a hard practice to master. You need to be good at testing, design, and refactoring, among other things, so it's definitely not the first thing you want to learn when you are inexperienced.
I'd say that you should develop the habit of writing automated tests first, and, eventually, you can try the TDD process, to see if it's a good fit for you.
That's more or less what I did. I didn't try TDD until I was confident with my design and testing skills.
I hope this helps!
Automated tests play the role of code samples.
I'd like to emphasize this sentence, code samples are super helpful.
It even affects the whole design of a feature. Especially, when developing the API, first, and then the implementation, like how we do in TDD.
Good writing style, by the way. Thanks!
Thanks Reza! 🙏
Yes, that's an important benefit. When we write tests, we are effectively using our APIs. If the design is bad, our tests will suffer (e.g. they will be less readable). This is one of the ways testing has a strong positive impact on design.
That's an awesome article, I have to admit that I loved it a lot.
Really nice writing style, easy to read and understand. No complex sentences and very good arguments. It would be of a great benefits for the community around you if you keep posting such good content with this writing style.
Little remark about the following:
through the use of test doubles, also known as mocks
I talk about that in my last weekly video on youtube 👇, and basically there is some history of why the term Mocks is used in generic context to refer to all Test-Doubles, but the actual mock is a kind of test-double just like the stub, dummy, spy and fake.
Would be interesting to see your opinions on that especially after watching the video: youtu.be/YQ9qlcq6Yyg
Thanks Jovche for the feedback!
I am aware of the different types of test doubles. I typically use the terminology that is presented in the "xUnit Test Patterns" book. But, in this article, I used the term "mock" because it's well-known by many people, despite the fact that, as you rightly suggest, it is just yet another type of test double.
You can expect my feedback on your video soon 😉
It's lovely to see we are on the same page :) Indeed the term is widely used and know in the community 💯👌
Nice Article Mario Cervera. Enjoyed reading every point you have mentioned
Very Clear & concise points👍
Thanks Apoorv! Glad to hear that you liked it! This kind of feedback encourages me to write more posts in the future 😊
Amazing as usual, Mario !
Thanks Maxi! I really appreciate it! Getting such positive feedback, no doubt that I will write more articles soon 😉
Amazing as always Mario! Looking forward to a nice post about clean code and more examples about testing!
Thanks for sharing!
Thanks Matt! Those posts that you mention will come, eventually 😉
I have a few questions?
Is there such a thing as "over testing"?
What is the industry benchmark for percentage coverage?
Yes, there's such a thing. Your time is not infinite, so you cannot possibly test everything or automate everything. You want to automate tests that prove different things, so that they are more useful. For example, to test a "multiply" function, it is probably better to use as test inputs (3,0), (7, 16), (-2,8), and (1242362234, 35674563), which prove different things, than using (1, 1), (2,2), (3,3), and (4,4), which leave some corner cases untested.
No, there is no benchmark. The ideal is 100%, but it is unattainable, and, at the same time, anything less than 100% can be considered bad (because you want a 100% of your app to work, right?). My opinion is that you have to use code coverage as a "motivation metric". That is, always try to improve it, knowing that you won't reach 100%, but the higher the better.
Mario Cervera Thanks for your reply
Thanks Mario, great article!
Tests help you detect errors early, when they are cheapest to fix.
Agreed 100%. The sooner you fix it, the more time you will save in the future.
Thanks Nick! I am happy that you like it 😊.
Yes, short-sighted people usually argue that testing slows the team down, but they fail to consider the savings that come in the future!