how to write a junit test to see what is returned?

Question

very new to writing unit tests. can someone help me write a test for this

public List<PspTransaction> mapToDomainList(List<PspTransactionEntity> entityList) {
        List<PspTransaction> domainList = new ArrayList<PspTransaction>();
        for (PspTransactionEntity entity : entityList) {
            domainList.add(map(entity, new PspTransaction()));
        }
        return domainList;

I want to know which things are good to test and an easy guide so I can learn for the future. Futhermore, I really want to know how to see if domainList is returned. is it assertTrue?

Check this [link](http://stackoverflow.com/questions/3236880/assert-list-in-junit) — TheGaME, Jan 07 '15 at 16:06
One thing you should not be testing here is `map(...,...)`. That needs to be in a separate test — David Soroko, Jan 07 '15 at 16:46

score 1 · Answer 1 · answered Jan 07 '15 at 16:22

Generally speaking there are several things you can test here.

Test whether if you enter an empty list you get an empty list back.
Test whether if you enter a non empty list you get back a list with the same number of elements.
Test whether if you enter a non empty list with known values the result contains values which look like they are the mapped values you were expecting. DO NOT test the mapping itself though; that should be done in a separate test for the map function.
Test negative cases, e.g. passing null to the function.

Methods that will help you in these tasks would be:

assertNotNull
assertEquals
assertTrue
assertThat
and the Annotation @Test(expected = ExpectedException.class) (where of course you replace ExpectedException with the type of Exception you're expecting).

score 1 · Answer 2 · answered Jan 07 '15 at 16:52

I would encourage you to try to think of the outcome you want to test first and then write some code to make the test pass (TDD). This can help you with developing good interfaces and designing easily understood classes that you may even be able to re-use.

A couple of rules of thumb here are that you want your classes to have one responsibility and your methods to do one thing--in essence, it's the KISS principle, but with some specific design hints. Also, I like to think of tests for behavior rather than tests for methods--it's a subtle difference which I will find difficult to explain!

Here I have a method to test before I have thought about what I really intend for the system to do, so I find it harder to work this way, but I'll share my thoughts. I like to use AssertJ assertions.. I'm just winging this, so it hasn't seen a compiler.

import static org.assertj.core.api.Assertions.*;
...

private TestSubject testSubject = new TestSubject(); // instance of the class under test (you omit the actual class name)
...

@Test
public void should_return_empty_list() {
    // Arrange
    List<PspTransactionEntity> input = new ArrayList<PspTransactionEntity>();

    // Act
    List<PspTransaction> mapResult = testSubject.mapToDomainList(input);

    // Assert
    assertThat(mapResult.size()).isEqualTo(0);
}

@Test(expected=java.lang.NullPointerException.class)
public void should_throw_null_pointer_exception() {
    // Act
    List<PspTransaction> mapResult = testSubject.mapToDomainList(null);
}

So, I guess I would want tests along those lines if I'm working backwards from the code to the tests. Think of the happy path but also your edge cases like what should happen when you pass null, etc. Does it make sense? Hope it helps!

In many cases it makes sense to create a new `TestSubject` for each Test run; after all, it may hold a state, which would make one test influence another. — blalasaadri, Jan 07 '15 at 18:30
Agreed @blalasaadri. Am not sure if the behavior as I illustrate is materially different from instantiating the test subject in a method annotated with at-Before, however. Well, anyway, was just trying to convey the idea here. — unigeek, Jan 07 '15 at 18:42
Initializing it in an @Before-Method should work just as well. To keep it simple it's probably a good idea to initialize it in the method though; that may save the OP from weird errors and is easy enough to understand. — blalasaadri, Jan 07 '15 at 18:47
For purposes of illustration, instantiating the object in the test subject in the test method would be fine. The obvious drawback, however, is the potential for copy/paste abuse by the next coder faced with this example. Trying to keep the tests "DRY" also. — unigeek, Jan 07 '15 at 18:53

score 0 · Answer 3 · answered Jan 07 '15 at 16:17

0

Looks like domainList will always be returned since you just create a new one inside the mapToDomainList method. So you need to check if it is not empty with something like assertFalse(returnedDomainList.isEmpty()); This will work if entityList is not empty.

If entityList is empty you can assert that your returned list is as well empty.

answered Jan 07 '15 at 16:17

panagdu

2,133
1
21
36

so the test will fail if entityList is not empty? how would it be written to pass both times regardless of outcome? – Jan 07 '15 at 16:46
@BlackMagma You should have two tests. – panagdu Jan 07 '15 at 16:49

how to write a junit test to see what is returned?

3 Answers3