Chapter 15 - JUnit Internals

• Goes through the ComparisonCompactor Test cases, self explanatory if you read the code.
• This module and code is part of the JUnit framework which is used to compare strings
• Shows the ComparisonCompactor code
  • Clean format
  • Constants at the top followed by variable declarations
  • Good flow of functions and declaring the functions that have been called by the previous functions.
• Attempts to improve the original code for ComparisonCompactor
  1. Removes prefix for the global variable declarations ('f')
  2. Encapsulates the condition statement to a seperate function 'shouldNotCompact', however the naming can be better
  3. Changes the variable names to be unambiguous
  4. Back to step 2 about the naming, inverts the sense of the condition to be 'canBeCompact' and instead of using '== ||' use '!= &&'.
  5. Changes the name of the function which compacts the strings to 'formatCompactedComparison' because if the condition is false then it doesn't compact the string.
  6. Extracts the body of the if statement of compacting expecetd and actual string into their own method 'compactExpectedAndActual'
  7. Following the consistency of the other functions, made the findCommmonPrefix/Suffix functions to return the index value. Now it doesn't need to rely on the global variable prefix/suffix
     • With these functions, there is coupling because the suffix relys on the prefix index first, so need to give it the prefix index argument
  8. Decides that step 7 is not a great solution, so combines both methods into a single function and have that parent function call both of the functions
  9. Changes the suffix index because its not zero based, and changes it be consistent with the other indexes.
     • Also changes the prefix/suffix index variables into length
  10. Restructures the compactString to remove the if statements and make it more simple.
• Shows the final result of the refactor. Reverse some of the decisions as well.
• Often refactoring leads to another refactor which undos decisions made in the first refactor.
• Refactoring is an iterative process, and is often trial and error.
• Reinforces the boy scout rule of leaving the code cleaner than when you found it. No code is immune from improvement