Day 5 of the Exoftware Agile Course at UCD Dublin

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:

Exoftware Logo

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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s