When I'm testing my simple geometric library, I usually have one or two methods in every test class. All I check is whether objects do proper coordinates calculation or not. Is it okay (meaning the number of methods)?
+2
A:
This is fine - it's not about having a million tests - it's about getting reasonable coverage. If you later find a bug, you can add a new test that exposes that bug before fixing it so your tests get better over time.
Sohnee
2009-10-27 09:26:14
+1 - I find this is a good way to test, it's also good at finding and fixing edge cases which might go a bit crazy depending on certain setups.
WestDiscGolf
2009-10-27 11:00:59
+8
A:
Don't get hung up on the number of methods. Just think about the ways in which your code could fail and add tests, preferably as separate methods, as you think of them.
The reason for separate methods is mostly to allow each test to be focused on just one aspect of your code and therefore keeping the test code short and simple to understand.
It's also acceptable to have a test method perform a number of Assertions, but once again these assertions should be checking a similar aspect of your code.
In some cases test code may need to be more complex eg: longer methods with calls to helper methods, but in general it is often possible to avoid this.
A good practical book that I've read on unit testing is Pragmatic Unit Testing in C# with nUnit. It provides handy guidance on many questions such as this.
Ash
2009-10-27 09:30:22
don't forget to think of all the ways your code should succeed as well as ways the code should fail. Tests should cover success ('happy path') as well as failure ('sad path'). Think of tests as specification instead of proof or evidence.
tottinge
2009-10-30 18:43:55
+4
A:
There is no inherent problem with that, nor does it indicate a test smell in itself.
In general, there are several different patterns for arranging test cases in classes. The book xUnit Test Patterns list several of them:
- Testcase Class per Class
- Testcase Class per Feature
- Testcase Class per Fixture
Normally, the most common pattern is Testcase Class per Class, which means that you have a class contiaining test cases that all target the same System Under Test (SUT). That can sometimes lead to small test classes, but it's not a problem.
Mark Seemann
2009-10-27 09:33:44
A:
My 2c/2p:
As others have said - it's not about the number of feature points tested, but it IS about isolation of each feature. So I would be wary of dependencies within each test - if you are dependent on one feature to produce an outcome/state/result which another feature uses in the same test then you have multiple possible points of failure.
Assuming you follow the Arrange/Act/Assert pattern, I certainly think it is OK to do multiple asserts on multiple objects after a single action.
Gordon Mackie JoanMiro
2009-10-27 10:57:04