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 assertion ?
A:
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.
Darin Dimitrov
2009-11-04 07:56:37
+4
A:
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.
Brian Rasmussen
2009-11-04 07:57:09
State in this case is presented how exactly? As a certain set of property values? In this case it's Assert as well.
Robert Koritnik
2009-11-04 08:09:55
@Robert: I am not sure exactly what you mean, but I have updated the answer, so lmk if it addresses your question.
Brian Rasmussen
2009-11-04 08:14:00
@Brian: What I meant was that checking certain state are actually assers against some object properties (their values). So they are just regular asserts. In the second part of your answer you are referring to mock verifies. Anyway. I don't think these comments matter.
Robert Koritnik
2009-11-04 12:18:45
A:
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...
Dani
2009-11-04 07:58:02
A:
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.
Thomas Weller
2009-11-04 07:59:17
Oh, really? I don't know MSTest, I had the xunit frameworks like NUnit, MbUnit or xUnit.net in mind. And what you say is another reason to not using MSTest...;-)
Thomas Weller
2009-11-04 10:16:23
+5
A:
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.
Robert Koritnik
2009-11-04 08:02:55
Sometimes, especially in C/C++ world, your test might be checking if "the code compiles". This isn't a joke - all preprocessor macros should have a "MACRONAME_Compiles" test, and it should be the very first test for it, passing various forms of parameters (expressions as parameters are often used in such tests).
Paulius Maruška
2009-11-04 08:26:54
@Rich: It was meant that way... I've rephrased my answer. Because we may be checking positives as well as negatives. Which one seems more appropriate.
Robert Koritnik
2009-11-04 08:36:35
could u pls give me an example for "check that exceptions behave (fire or not) as expected" When it will fire any exeption,the test will break.
2009-11-04 10:10:08
@unknown: Test will automatically fail when there's an unexpected (as an unconfigured with unit test) exception in the call.
Robert Koritnik
2009-11-04 12:15:15
+2
A:
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.
mouviciel
2009-11-04 08:46:51
A:
Of Course there is something like Assert.Throws/Assert.DoesNotThrow in MSTest there are Assert.Fail() and AssertFailedException()
Wolfgang.Kinner
2009-11-04 15:29:50
A:
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.
ndp
2009-11-05 07:55:27