how to unit test a class which creates new objects

Question

I'm using JUnit and Mockito to test some classes. The class itself creates an object from another class. A list called testList. Here my code:

public class A { private List<B> bList; //returns the bList public List<B> getBList() { return bList; } //checks the status by calling getStatus in class B public Status getStatus() { //status is an enum consists of PASSED and FAILED Status finalStatus = Status.PASSED; for (B be : this.getTestList()) { if (be.getStatus() != Status.PASSED) { finalStatus = Status.FAILED; break; } } return status; } } public Class B { private Status status = Status.FAILED; public getStatus() { return status; } public void setStatus(Status status) { this.status = status; } }

What would be the best way to test the getStatus and getTestList methods in the class called Test.

Thank you very much....

The two clases with Test in the name are not actually tests. In a discussion about testing that's a bit of a head bender. — Simon Gibbs
– Simon Gibbs, Commented Oct 5, 2012 at 16:19
@SimonGibbs Thats true. The classes I posted aren't tests, these are the classes which should be tested. Let us imagine the classes would be named A and B :) — Funky Monkey
– Funky Monkey, Commented Oct 5, 2012 at 16:33
I agree with simon about the head bender. Btw have you tried capture? — bluesman
– bluesman, Commented Oct 5, 2012 at 16:40
I changed the class names. You are right, they have been confusing. My problem: How do I test the method getStatus in class A, because it's using the external method getStatus from class B. Are there any ways with mock objects? — Funky Monkey
– Funky Monkey, Commented Oct 5, 2012 at 16:50

Dawood ibn Kareem · Accepted Answer · 2012-10-05 18:17:10Z

I looked at your ClassA and I wondered how bList ever gets set to anything. Right now, there's no way for it to be anything other than null, which means that getStatus will throw a null pointer exception every time.

Your problem is that you are thinking about how to test methods instead of thinking about how to test behaviour. One reason why this is a problem is that your class has to fit in with the rest of your application in a certain way. To be sure that it does that, it needs certain behaviour, not certain details within each method. So the only meaningful test is one that checks the behaviour.

Perhaps more insidious is the fact that testing individual methods makes you focus on the code that you have in fact written. If you are looking at your code while you write your test, then your test becomes a self-fulfilling prophecy. You may have missed a whole set of behaviour that your class is required to provide; but if you only test the behaviour that your class does provide, you'll never know.

So, back to the problem in hand. I see four, maybe five behaviours that your class might be expected to fulfil. Maybe there are more - it's hard to tell if you only show us the code, and not the specification. You should write a test for each one. I strongly believe that the name of each test should describe the behaviour, rather than reflecting the name of the methods that the test uses. In this case, I might choose names like this.

public void statusIsPassedWhenEveryTestPassed() public void statusIsFailedWhenEveryTestFailed() public void statusIsFailedWhenSomeTestsPassedSomeFailed() public void statusIsPassedWhenNoTests() public void statusIsPassedWhenTestsNotSet() // this one currently fails

Within each test, I would create an object of ClassA, then do whatever has to be done to set the bList within the object. Lastly, I would call getStatus and assert that the return value is what I want. But the important point is that each test (except the last one) uses more than one method of ClassA, so these are not tests of an individual method.

thank you public final void testGetBListIsEmpty() public final void testGetBListIsNotEmpty() public final void testGetStatus_StatusIsPassedWhenNoB() public final void testGetStatus_StatusIsPassedWhenEveryBPassed() public final void testGetStatus_StatusIsFailedWhenOneBIsNotPassed() public final void testGetStatus_StatusIsFailedWhenSomeBAreNotPassed()

Ravi Bhatt · Accepted Answer · 2012-10-05 16:37:35Z

You can provide setters (or constructor injection) for the objects in question as protected and then extend the class inside your test case to mock the objects or you can try using something like powermock. You would still need to provide a way to set those objects in question.

denis.solonenko · Accepted Answer · 2012-10-05 16:48:25Z

I guess it depends on how you can populate testList in a unit test. If you have, say, a setter, then you would not need any mocking frameworks

class TestTest { Test test = new Test(); @Test void should_return_failed_if_a_single_test_failed() { givenTestListWithOneFailedTest(); assertThat(test.getStatus(), is(Status.FAILED)) } void givenTestListWithOneFailedTest() { test.setTestList(createSomeTestListWithOnlyOneFailedTest()); } @Test void should_return_passed_if_all_tests_passed() { // ... } }

Collectives™ on Stack Overflow

how to unit test a class which creates new objects

3 Answers 3

1 Comment

Comments

Comments

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

1 Comment

Comments

Comments

Related