Databases
StackOverflow2013
Postsdbo
POHow to Unit Test this (use mocks, or classical unit test?)
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to Unit Test this (use mocks, or classical unit test?)
    primarykey
    data
    text
    <p>I need to write a JUnit test for the following method (simplified):</p> <pre><code>/** Return name of previous entry or name of given entry if no previous entry. */ public String getPreviousName(TreeEntry entry) { if (entry.getPrevious() != null) { return entry.getPrevious().getName(); } else { return entry.getName(); } } </code></pre> <p>I just don't know how I should test this. I could either</p> <p>a) Use Mocks to mock out the parameter and its previous entry or</p> <p>b) Create a real TreeEntry and it's real previous entry</p> <p>The problem with using mocks is, that I need to say in the test case which method the actual implementation needs to use, e.g. here I say the correct name is obtained via getPrevious() of TreeEntry and then via getName() of that previous entry (not considering the if null case, because that's basically not the problem):</p> <pre><code>TreeEntry mockEntry = mock(TreeEntry.class); TreeEntry mockPreviousEntry = mock(TreeEntry.class); when(mockEntry.getPrevious()).thenReturn(mockPreviousEntry); when(mockPreviousEntry.getName()).thenReturn("testName"); assertEquals("testName", classUnderTest.getPreviousName(mockEntry)); </code></pre> <p>But an implementer could for example also implement it like that:</p> <pre><code>return NameService.getName(entry.getPrevious()); </code></pre> <p>It just doesn't matter for the test.</p> <p>However, if I use classical unit testing without mocks I have another problem. The constructor of TreeEntry is very complex. It has 5 parameters that need valid objects. So it's very complex to create something like:</p> <pre><code>TreeEntry entry = new TreeEntry(...); TreeEntry previousEntry = new TreeEntry(...); entry.setPrevious(previousEntry); previousEntry.setName("testName"); assertEquals("testName", classUnderTest.getPreviousName(entry)); </code></pre> <p>The code would be much longer than this, because the constructors take complex parameters. Another thing is that the constructor accesses the file system to load it's contents from there, so it adds to making the unit tests slower.</p> <p>Using the classical approach it also ties the test a lot more to the implementation of TreeEntry. Because if something is changed in TreeEntry with the constructors or the setting of the previous entry it will also need to be changed in the test. And if it's forgotten it will cause the test to fail even tough the class under test is not TreeEntry.</p> <p>What would you say is the correct way to unit test this?</p> <p>I personally tend to like the mocking approach more. Is it maybe okay to say that in a test case I already specify which are the collaborators of the class under test because that in some way also belongs more to the design rather than the implementation?</p> <p>Best regards, Alex</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POHow to Unit Test this (use mocks, or classical unit test?)
      1. USEric
      1. VTFavorite
    2. VO
      singulars
      1. POHow to Unit Test this (use mocks, or classical unit test?)
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POHow to Unit Test this (use mocks, or classical unit test?)
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload