0

I am somewhat new to TDD and JUnit, I know that I can write test cases for methods I am implementing in my code.

And obviously, there are methods in my code which need several corner cases to be tested in order to verify that method implementation is OK. Since generally the good practice is keeping one test method per one method in code, I have to add multiple assertions for that kind of a method as explained in this answer. https://stackoverflow.com/a/762582/5715934

public void testValueOf() {
    assertEquals(1, Integer.valueOf("1").intValue());
    assertEquals(0, Integer.valueOf("0").intValue());
    assertEquals(-1, Integer.valueOf("-1").intValue());
    assertEquals(Integer.MAX_VALUE, Integer.valueOf("2147483647").intValue());
    assertEquals(Integer.MIN_VALUE, Integer.valueOf("-2147483648").intValue());
....
}

But when I am executing the test case, I am not getting test status (pass/fail) for each assertion inside the test method. Instead, it shows 'red' even if one assertion is failed and green if all are passed.

Isn't it easier to have the track of each assertion to make debugging easier? And is there any formal way/tool/workaround to do that (JUnit 4)?

Community
  • 1
  • 1
Supun Wijerathne
  • 11,964
  • 10
  • 61
  • 87
  • 1
    It is a *Bad Practice* to have a single test per single method. You should have a separate test for different test cases always. – Krzysztof Krasoń May 16 '16 at 06:01
  • As that answer in the link explains, even inside one test method there are different cases (each as a different assertion). – Supun Wijerathne May 16 '16 at 06:03
  • @krzyk is right. Separate out all your test cases so you can tell which one fails and for what reason. This makes it much easier to tell why your test cases fail. They should also be independent of each other to ensure that no one test case can cause another to fail. – Dale May 16 '16 at 06:06
  • @Dale, krzyk Point taken -> (if there's no particular answer to this question I posted), It is much easier to method out the each assertion to see which test case (an assertion before) fails. But on the other hand think a situation like this. When you run all your test methods at once when you build, you can see 20 of them are failing. If you have implemented multiple test methods as you suggested, we have to manually check which methods are having problems inside the 20 methods failing. Isn't it? – Supun Wijerathne May 16 '16 at 06:22
  • Actually, you shouldn't. A method should have a singular functionality and return a result. If it is doing 20 different things then you may want to break them out thus making it easier to test each task that is to be done. – Dale May 16 '16 at 06:25
  • 1
    Like @krzyk said, it usually considered as **Bad Practice**, but the important thing is **why** it's bad, and you can **decide** to use it or not. Not all so called Bad Practices are forbidden, they just are usually misused. If you read the linked answer, you can see it described the pros and cons. – Nier May 16 '16 at 06:27
  • @Nier agree with your point. – Supun Wijerathne May 16 '16 at 06:32
  • @Dale I think you have got my statement wrong. – Supun Wijerathne May 16 '16 at 06:32
  • Why would you be checking 20 test methods? How much is one method doing? – Dale May 16 '16 at 06:35
  • 1
    @SupunWijerathne If you have 20 methods failing, it means all of them are having problems, and you can track any of them to find the **source** of the problem. Once you solve that problem, run the test cases again to see how many test cases remain failed. The pros of separate each assertion (or more precisely, concept) into different test cases is that you can know what exactly going wrong. If you mixed up many concepts in a test case, it will be harder to tell what's wrong and what needs to be fixed. So **think** before you decide to do it, if you think it's OK in the case then it's fine. – Nier May 16 '16 at 06:46
  • 1
    Okay. I see where you're going. Unit testing should test methods independently. If you have 20 methods failing in your tests because of some other dependent method then you aren't really creating Unit tests but subsystem tests or integration tests. A true unit test would mock out dependencies thus removing the chance of other methods failing. However if your tests are truly subsystem tests or integration tests then yes, correct. I was assuming you wanted to do unit testing. – Dale May 16 '16 at 06:53
  • 1
    Back to the original question, I think there's a duplication in [this question](http://stackoverflow.com/questions/10221891/continuing-test-execution-in-junit4-even-when-one-of-the-asserts-fails). – Nier May 16 '16 at 06:54
  • @Dale Agree with you and yes, my previous comment could be confused at that context. – Supun Wijerathne May 16 '16 at 07:32
  • @Nier Thanx for your explanation. And the duplication you have specified, yes I can see it as an acceptable answer. Thanx. Before marking as duplicate, still I like to let anyone some time to answer this if someone gets a better answer. – Supun Wijerathne May 16 '16 at 07:34

1 Answers1

1

First of all it is NOT a good idea to have a single test method for single method, quite the opposite. In your code above each of the asserts should actually be a separate test method. This doesn't mean that you will always have a single assert in test method, this will be the case only for the simplest ones. If a method e.g. returns an object you will have more asserts that validate that this object is good.

But the most important thing is that the method under tests is called usually only once.

The only way to know which assertion failed is by looking at the message/stack trace. But generally if a test fails you know that something is wrong, you open IDE and look at the test.

Krzysztof Krasoń
  • 26,515
  • 16
  • 89
  • 115