Schlagwort: testing

genericandwildcard Daily Coding Knowledge ,

#6 One thing to look out for when using LiveData and Transformations

If you were to unit test LiveData and LiveData transformations you might write a test like this:

  1. class MainViewModel(initialArticle: Article) : ViewModel() {
  3. private val _articleLiveData = MutableLiveData<Article>()
  4. val articleLiveData: LiveData<Article> = _articleLiveData
  5. val articleTitleLiveData: LiveData<String> = Transformations.map(_articleLiveData) { it.title }
  7. init {
  8. _articleLiveData.value = initialArticle
  9. }
  10. }
  12. class MainViewModelTest {
  14. @get:Rule
  15. var rule: TestRule = InstantTaskExecutorRule()
  17. private lateinit var viewModel: MainViewModel
  19. private val initialArticle =
  20. Article("first Article", "text of first article. blablalbalb. blalbla. bla.")
  22. @Before
  23. fun setup() {
  24. viewModel = MainViewModel(initialArticle)
  25. }
  27. @Test
  28. fun testArticleEmission() {
  29. Assert.assertEquals(initialArticle, viewModel.articleLiveData.value)
  30. }
  32. @Test
  33. fun testArticleTitleEmission() {
  34. Assert.assertEquals(initialArticle.title, viewModel.articleTitleLiveData.value)
  35. }
  36. }
class MainViewModel(initialArticle: Article) : ViewModel() {

    private val _articleLiveData = MutableLiveData<Article>()
    val articleLiveData: LiveData<Article> = _articleLiveData
    val articleTitleLiveData: LiveData<String> = Transformations.map(_articleLiveData) { it.title }

    init {
        _articleLiveData.value = initialArticle
    }
}

class MainViewModelTest {

    @get:Rule
    var rule: TestRule = InstantTaskExecutorRule()

    private lateinit var viewModel: MainViewModel

    private val initialArticle =
        Article("first Article", "text of first article. blablalbalb. blalbla. bla.")

    @Before
    fun setup() {
        viewModel = MainViewModel(initialArticle)
    }

    @Test
    fun testArticleEmission() {
        Assert.assertEquals(initialArticle, viewModel.articleLiveData.value)
    }

    @Test
    fun testArticleTitleEmission() {
        Assert.assertEquals(initialArticle.title, viewModel.articleTitleLiveData.value)
    }
}

But it might surprise you that the 2nd test testArticleTitleEmission will fail. Why is that?

Turns out that transformed LiveData does not emit values without an observer. So to make the test pass you need to adjust it in the following way:

  1. @Test
  2. fun testArticleTitleEmission() {
  3. viewModel.articleTitleLiveData.observeForever { } // This is the important bit!!
  4. Assert.assertEquals(initialArticle.title, viewModel.articleTitleLiveData.value)
  5. }
@Test
fun testArticleTitleEmission() {
    viewModel.articleTitleLiveData.observeForever { } // This is the important bit!!
    Assert.assertEquals(initialArticle.title, viewModel.articleTitleLiveData.value)
}

Note: It doesn’t matter what your observer does, just that it exists.

Now both tests will pass.

genericandwildcard Daily Coding Knowledge ,

#4 Testing: The disadvantage of static methods

What are static methods?

  • Static methods belong to the class rather than an instance of the class.
  • Static methods are not inherited and thus cannot be overridden.
  • You cannot use static methods for declaring a contract via an interface.

These facts are in themselves not bad.

Why are static methods bad for testing? 

Let’s say we want to test the following createCommand method using JUnit Jupiter:

  1. public class Mapper {
  2. public Command createCommand(final Event event) {
  3. return Command.builder()
  4. .commandUuid(UUID.randomUUID().toString())
  5. .id(event.getEventId())
  6. .name(event.getName()).build();
  7. }
  8. }
  10. @Builder
  11. @Getter
  12. @EqualsAndHashCode
  13. public class Event {
  14. private String type;
  15. private String eventId;
  16. private String name;
  17. }
  19. @Builder
  20. @Getter
  21. @EqualsAndHashCode
  22. public class Command {
  23. private String commandUuid;
  24. private String name;
  25. private String id;
  26. }
public class Mapper {
    public Command createCommand(final Event event) {
        return Command.builder()
                .commandUuid(UUID.randomUUID().toString())
                .id(event.getEventId())
                .name(event.getName()).build();
    }
}

@Builder
@Getter
@EqualsAndHashCode
public class Event {
    private String type;
    private String eventId;
    private String name;
}

@Builder
@Getter
@EqualsAndHashCode
public class Command {
    private String commandUuid;
    private String name;
    private String id;
}

But mocking the static UUID.randomUUID() method is not possible with most testing frameworks. This is where the problems starts:

We don’t know what to put as commandUuid because it get’s generated inside the mapping by using a static method. This dependency is hidden for us.

  1. public class TestMapping {
  3. @Test
  4. public void testMapping() {
  5. Mapper mapper = new Mapper();
  6. String eventId = UUID.randomUUID().toString();
  7. String name = "name";
  8. Event event = Event.builder()
  9. .eventId(eventId)
  10. .name(name)
  11. .type("create")
  12. .build();
  13. Command command = mapper.createCommand(event);
  15. Command expected = Command.builder()
  16. .name(name)
  17. .id(eventId)
  18. .commandUuid("Don't know what to do here? ?")
  19. .build();
  21. Assertions.assertEquals(command, expected);
  22. }
  23. }
public class TestMapping {

    @Test
    public void testMapping() {
        Mapper mapper = new Mapper();
        String eventId = UUID.randomUUID().toString();
        String name = "name";
        Event event = Event.builder()
                .eventId(eventId)
                .name(name)
                .type("create")
                .build();
        Command command = mapper.createCommand(event);

        Command expected = Command.builder()
                .name(name)
                .id(eventId)
                .commandUuid("Don't know what to do here? ?")
                .build();

        Assertions.assertEquals(command, expected);
    }
}

So what could do we do instead?

  1. add dependencies for Mockito and Mockito JUnit Jupiter support
  2. Create UuidGenerator class with a generateUuid() method (if you want you could even go with an interface, but let’s keep it simple for now)
  3. inject UuidGenerator instance to the Mapper class.
  4. Mock the UuidGenerators generateUuid method to always return the same uuid.

Our code will now look like this:

  1. public class UuidGenerator{
  2. public String generateUuid(){
  3. return UUID.randomUUID().toString()
  4. }
  5. }
  7. public class Mapper {
  9. private final UuidGenerator uuidGenerator;
  11. public Mapper(UuidGenerator uuidGenerator) {
  12. this.uuidGenerator = uuidGenerator;
  13. }
  15. public Command createCommand(final Event event) {
  16. return Command.builder()
  17. .commandUuid(uuidGenerator.generateUuid())
  18. .id(event.getEventId())
  19. .name(event.getName()).build();
  20. }
  21. }
  24. @ExtendWith(MockitoExtension.class)
  25. public class TestMapping {
  27. private Mapper mapper;
  29. @Mock
  30. private UuidGenerator uuidGenerator;
  32. @BeforeEach
  33. public void before() {
  34. mapper = new Mapper(uuidGenerator);
  35. String commandId = UUID.randomUUID().toString();
  36. Mockito.when(uuidGenerator.generateUuid()).thenReturn(commandId);
  37. }
  39. @Test
  40. public void testMapping() {
  41. String eventId = UUID.randomUUID().toString();
  42. String name = "name";
  43. Event event = Event.builder()
  44. .eventId(eventId)
  45. .name(name)
  46. .type("create")
  47. .build();
  48. Command command = mapper.createCommand(event);
  50. Command expected = Command.builder()
  51. .name(name)
  52. .id(eventId)
  53. .commandUuid(uuidGenerator.generateUuid())
  54. .build();
  56. Assertions.assertEquals(command, expected);
  57. }
  58. }
public class UuidGenerator{
    public String generateUuid(){
       return UUID.randomUUID().toString()
    }
}

public class Mapper {

    private final UuidGenerator uuidGenerator;

    public Mapper(UuidGenerator uuidGenerator) {
        this.uuidGenerator = uuidGenerator;
    }

    public Command createCommand(final Event event) {
        return Command.builder()
                .commandUuid(uuidGenerator.generateUuid())
                .id(event.getEventId())
                .name(event.getName()).build();
    }
}


@ExtendWith(MockitoExtension.class)
public class TestMapping {

    private Mapper mapper;

    @Mock
    private UuidGenerator uuidGenerator;

    @BeforeEach
    public void before() {
        mapper = new Mapper(uuidGenerator);
        String commandId = UUID.randomUUID().toString();
        Mockito.when(uuidGenerator.generateUuid()).thenReturn(commandId);
    }

    @Test
    public void testMapping() {
        String eventId = UUID.randomUUID().toString();
        String name = "name";
        Event event = Event.builder()
                .eventId(eventId)
                .name(name)
                .type("create")
                .build();
        Command command = mapper.createCommand(event);

        Command expected = Command.builder()
                .name(name)
                .id(eventId)
                .commandUuid(uuidGenerator.generateUuid())
                .build();

        Assertions.assertEquals(command, expected);
    }
}

One could argue that we could write a custom equalsData() function or something similar. Or check for all fields separately? But what if we’ll change one of the Event or Command classes? We would always need to think about adjusting these methods and imagine bigger data classes with lots of fields: everything would get very cluttered.

Apart from that this is just an example, this principle is applicable to many more cases.