Should every test method have at least one assert?

When I'm testing a void method there is nothing to assert.For example a CreateSomething method. I know I could call in the test method an other method like FindSomething,but anyway, if there is (in the create method) an error it will show up. So it's a good practice to call an assertion in every method or i'm fine sometimes without an ass开发者_开发技巧ertion ?

Not necessarily an Assert

But your test code should do at least one of these:

• assert that some property/result has/hasn't been set to particular value
• verify that certain methods have been called/avoided
• check that exceptions behave (fire or not) as expected

So it's values, actions and errors that you should be checking. Sometimes just one of these, sometimes you can't do it without a combination.

Void methods oftentimes change the state of an instance. In that case, your test method should assert that the expected state is present after the call. I.e. you need to assert on the state of relevant members.

Void methods with no side effects can also be tested using mock object. In this case you'll test that the method makes the expected calls on the mock object.

Having said that function like methods should be preferred IMO as they are easier to reason about and easier to test, but that is just my opinion.

When I'm testing a void method there is nothing to assert.

So, what is the purpose of the method?

Answering this question helps to find what is to be asserted. If the anwser is actually nothing, you should be able to remove that method from your code with no impact.

Implementing the test code for covering this assertion is another problem which may or may not be easy or relevant given your development environment or the constraints of the project.

It is not necessary to have an assert in each test method. For example if you want to test that your method will throw an exception you could use the ExpectedException (MS Test). If you are not testing that your method throws an exception and you don't have a single assert then you might be doing something wrong. Just calling a method is not a good unit test. You need to verify somehow if this method performed as expected after you call it which is usually achieved through asserting.

Well, if you only need to test that the method runs... wrap it in try and catch, and if it fails for some reason (and you can't assert anything) - assert(false) in the catch, or if you expect an exception - use ExpectedException...

You should definitely assert at least one fact in every test. Simply because your unit test framework will count the number of assertions, and the measure number of tests/number of assertions can give a good first impression about a test suite.

If there is seemingly nothing you can assert: All unit test frameworks that I know have Assert.Throws/Assert.DoesNotThrow methods for exactly that purpose.

Of Course there is something like Assert.Throws/Assert.DoesNotThrow in MSTest there are Assert.Fail() and AssertFailedException()

Make sure it fails if what your testing is broken. This can be witnessed by:

• assert
• exception thrown
• mock object complaining it didn't get called correctly

Maybe there are some exceptions to this, but I can't think of any. One principal of TDD is important here:

Write the failing test first.

If you do that, you're guaranteed it's a good test.

Some people claim that each test should have one, and only one, assert... but that's a different question.