4

lately I'm coming deeper into unit tests and I kind of stuck.

Example. we have method like this:

boolean isCheckOutChecked(NmCommandBean clientData) {
    return "checkOut".equalsIgnoreCase(clientData.getTextParameter("checkOut"));
}

Most of it depends by what clientData returns. There are two possibilities:

  1. return null if can not find text parameter
  2. return string value if did


Well... I have created two tests but wondering if does it have any sense to have tests like this? What will you do in this scenario?

@Test
void shouldReturnTrueWhenCheckoutIsChecked() {
    doReturn("checkOut").when(clientData).getTextParameter("checkOut");

    boolean checkOutChecked = formProcessor.isCheckOutChecked(clientData);
    assertTrue(checkOutChecked);
}

@Test
void shouldReturnFalseWhenCheckoutIsNotChecked() {
    doReturn(null).when(clientData).getTextParameter("checkOut");

    boolean checkOutChecked = formProcessor.isCheckOutChecked(clientData);
    assertFalse(checkOutChecked);
}
Aramka
  • 111
  • 3
  • 10

2 Answers2

1

Since you have hard-coded checkOut I'd say yes, we have these kind of tests in our product - called "safety net" tests, in case someone changes on UI side that parameter, we want to fail in tests, not in real code.

Eugene
  • 117,005
  • 15
  • 201
  • 306
0

In places where there are conditions/branches, it is very useful to have unit tests, so that all the basic scenarios are covered in unit test cases itself. This reduces the feedback time (the application need not be deployed to test the condition) and helps in faster development.

Mamtha Soni K
  • 895
  • 6
  • 9