Choose one — 60 test cases or 10 for one function.
More the test cases, the better the code. So, 50.
If you choose 50,
It’s better don’t spend time on writing test cases, just do the development rather — it would be less waste of resources.
Why? Because 90% of the test cases here are completely useless.
If you’re following TDD in your project or doing testing but it’s not helping you to do this,
- Improved models — Think about your models first.
- Faster implementations — use short cycles to give you feedback more often.
- No obvious, workflow bug — enables you to get a different perspective on your code.
- No test case fail — see your tests as “living specifications” rather than after-the-fact tests.
- Debug fast
You need a new plan, your testing pipeline is completely faulty. You really need to question — Do you know testing?
So, The main point — How to know what testcases are required to add?
At GreyB, a simple rule list — your test case should fulfil the following rules (this is what even uncle Bob says):
- Test one thing and assert many
- You can’t test same kind of thing multiple times
- Every assertion such validate your test condition — don’t just code for success or fail [it will still be pretty useless]
- It should be something that can happen in production
Let’s take an example:
I have to write test case for a function with input — Name, Date
Possible Scenarios are:
And there can be hell lot more of them. From the comments if you see, the useful test cases have reduced to half.
Now what are actually useful test cases other than these 5:
- A date in different formats
- A username as a sentence
- Different kinds of characters in username
This makes it useful 8 test case that really works for the functionality. Now these things are context based and would test for what a user can actually do. Otherwise, there is finer testcase than what a user will perform.
Your tests should help you to test multiple things in least number of ways otherwise testing will never end and myths like 100% test coverage becomes true.
Would you like to get such bits of open test strategies in your inbox? Don’t forget to subscribe here.