Is it okay if my unit tests contain 1-2 methods per class?

When I'm testing my simple geometri开发者_高级运维c 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)?

---

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.

---

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.

---

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.

---

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.