SWE 437 Homeworks 5 and 6
Spring 2017
Tools: Mocking, Legacy TDD, Code Smells


There are three possible assignments over the next two weeks. You should choose one for assignment 5, and a different one for assignment 6. There is no additional credit for doing all three.

Collaboration is strongly encouraged on this assignment. See the syllabus for the constraints and the reward function. Use Piazza for help with getting tools to run.

  1. Pull down one of the Java mocking tools and write some interaction tests with that framework. There are lots of tools to choose from: EasyMock (what Koskela uses), JMock, Mockito (popular), and so on.

    You can use the examples from Koskela's book, or Fowler's Mocks aren't Stubs article, or another source.

    The point is that you are actually running the mock tests.

    Deliverable: A report that convinces me that you actually did the assignment. The GTA must be able to tell that your code runs.

  2. Create/find a legacy code example and work through Koskela's approach to working with legacy code (Section 4.6). This will mean identifying the change points, the inflection points, building a test harness that covers the inflection point, making the change, and (potentially) refactoring the covered code.

    Deliverable: Same as above. The GTA must be able to tell that your code runs.

  3. The goal of this exercise is focus in on just a couple of smells and associated refactorings. We'll use Koskela, since the code is right there. In particular, we'll focus on Listing 3.9, page 89.

    There are two smells identified in this chunk: "Primitive Obsession" and a violation of "Tell, don't ask".

    For one of these smells (your choice), I would like you to think about why the smell is bad. Specifically, engineer a fault into the code that is not plausible in the refactored version.

    Demonstrate your understanding by writing the relevant test in JUnit. Show that the faulty version fails the test, and argue that the specific fault isn't really realistic in the refactored version.

    Deliverable: Turn in a story, complete with code/test snippets. The GTA must be able to tell that your code runs.

Grading: Grading is a function of whether you followed the directions, and whether your story is coherent. Submissions where the GTA cannot tell if your code runs will not be graded. Submissions with an incoherent story will not be graded.