Changes between Initial Version and Version 1 of Ticket #22733, comment 5


Ignore:
Timestamp:
Dec 4, 2017, 9:52:24 AM (2 years ago)
Author:
iwakeh
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #22733, comment 5

    initial v1  
    77> As a (truly) random example, look at the various `testSearchBase64*` methods [https://gitweb.torproject.org/onionoo.git/tree/src/test/java/org/torproject/onionoo/server/ResourceServletTest.java#n633 here]. And now imagine how this would look like without test method names. Sure, it would be shorter. But would you still understand that the input data for `testSearchBase64HashedFingerprintTorkaZ` is the hashed fingerprint of one of the example relays? Stated differently, from looking at the data alone, would you be able to tell whether a given test case is already covered by existing tests or not?
    88
    9 The methods names hint about the test#s purpose, but are not really very helpful for the outside reader, being one word camel case.
     9The methods names hint about the test's purpose, but are not really very helpful for the outside reader, being one word camel case.
    1010
    1111>
    1212> I guess when we move to parameterized tests we should try to preserve the information that is currently contained in test method names. It could be in Java comments, though they might not be used or updated in practice. It could also be a String in yet another parameter (maybe first?) which might be printed out by JUnit in case of a failing test. Are there best practices for this issue, or how do others solve this?
    1313
    14 (answered above, ad the description string to the data)
     14(answered above, add the description string to the data)
    1515
    1616>