If you’re very observant , you might notice that this post is about a week late. Still , here are my notes on the slides / nodes from the final day of the Agile course.

Previous Posts from the training course are:

• Day 4
• Day 3
• Day 2
• Day 1

Junit Introduction

• Junit
  Framework for writing automated unit tests (don’t need to use Junit
  to write the tests , but it helps)

• All Junit
  tests extend TestCase

• Individual
  test methods (pre Junit 4.0) : public void testSomething() method
  signature

• Use
  assertEquals assertTrue assertFalse assertNull assertNotNull
  assertSame and fail methods for testing.

• SetUp() and
  tearDown() methods called before and after each test method.

• TestSuites
  (groups of TestCases) replaced by Ant and (Eclipse) IDE
  functionality

• Run tests via
  built in Text / Swing test running , or more likely use IDE / Ant
  integration.

• Organise via
  same or paralell folders

• TestMyClass
  or MyClassTest

Mock and Stubs

• Problem: some
  classes (Collaborating Objects) can be tightly bound to system
  resources (e.g. File or Database) or to a hard to test API. Another
  example is the observer pattern. How do we unit test these?

• Solution: use
  fake object , pass it to class under test , allows testing of the
  class at a unit level.

• Stub : fake
  object that uses hard-coded data , often following an API. Many
  ready made stubs available (e.g. For the JDBC libraries).

  • Replace
    expensive to create objects

  • Have to
    create all objects that production code interacts with.

  • Start in
    middle and develop outwards

  • One failure
    can ripple out / appear elsewhere.

• Crash Test
  Dummy: type of stub that deliberately fails in order to test
  exception handling – simulate database crash or I/O full.

• Self Shunt is
  where the unit test itself implements the interface (doesn’t work
  for classes) and gets callbacks from the class under test.

• Mock Objects
  like stubs, except that they are intelligent enought to self-verify.

  • Mock
    Secondary objects (normally ones that we build) instead of API (as
    Stub does)

  • Outside in
    development style

  • What if mock
    implementation is incorrect?

• Interaction vs. State: In
  state-based testing you check the tests by examining the state after
  the stimulus. In interaction based testing you check the right
  interactions were triggered by the stimulus – Martijn
  Fowler, http://martinfowler.com/articles/mocksArentStubs.html
  

• Mock objects
  tend to test more the interaction between objects rather than a unit
  test of the object itself.

• Stub rather
  than mock external API’s

Smells and refactoring.

• Code smells
  are bad or suspect design decisions in code.

• Not always
  bad , but should be looked at (often will involve a trade off)

• Smells are
  often hard to understand , hard to change code.

  • Samples :
    duplication / long methods / poor naming / tightly coupled classes
    / switch statements /

• Refactoring :
  Small , controlled changes to codebase , so that it continues to
  compile / tests run to improve the design. The behaviour remains
  exactly the same.

• Seperate
  refactoring and adding additional functionality.

• Easier with
  automated tools and Unit tests to confirm that nothing has broken.

• Refactoring
  != Rewrite. Codebase is evolved , not thrown away.

User Stories

• In some ways
  , equivalent to Use Case from Predictive methods (but with subtle
  differences).

• Represent
  chunk of functionality that makes sense to the customer.

• Can be
  represented as card / conversation / paper based documents (more
  predictive approach).

• In Agile (as
  opposed to predictive) , shift the focus from writing to talking
  i.e. Get a true understanding of what the customer wants , even if
  they haven’t expressed it very well.

• Lessen the
  importance of requirements

• Support
  iterative development and participatory design.

• Even a simple
  requirement has many possible permutations (that lessen the odds of
  getting it right.

• Not just a
  generic user – but more user roles – groups of users that do
  different things with the system , depending on their experience ,
  task at hand etc

• User Stories
  should be Invest:

  • Independent

  • Negotiable

  • Valuable

  • Estimatable

  • Small

  • Testable

• Templace
  (FlashCard , as used by Xplanner)

• Be careful of
  size

  • too big and
    cannot be used for estimated (break these down into smaller
    stories). Easy for Compound , but for complex stories might need to
    do some research and then break out.

  • Too small ,
    and it is not worth the admin of estimating each. Bundle them up
    into higher level task like UI improvements or bug fixes.

• User Story
  should give us the acceptance tests