In perhaps the worlds first use of a blog as an exam revision technique, here are the main features of Agile projects:

• Working Software over Comprehensive documentation
• Customer interaction over Contract negociation
• Responding to change over following a plan
• Individuals and interactions over processes and tools.

In the meantime , if you don’t have an exam this morning , check out the NoUnit Agile tool that we build and maintain.

Original Message

Hi Paul

How are you?when i was executing “ant unit-test-results” command then my
project is scuccessfully compiled but it was one error when executing
“unit-test” target it was not executing whole test cases and when executing
“unit-test-results” target I got the error :
“D:\test-director\nounit\build.xml:116: Could not find a valid processor
version implementation from *weblogic.xml.jaxp.RegistrySAXTransformerFactory
*”

please Paul help me as soon as possible.

with regards
Richa

Response
Not sure of the exact cause of the problem , but when I’ve seen this before it’s been caused by the wrong XSLT / SAX libraries in your classpath. I’m guessing that you’re running this on Weblogic, it might be worth getting the Apache SAX libraries and adding them to the start of your classpath.

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

These notes are a good complement to the Agile presentation I gave.

Introduction to Agile

• Requirements
  Change on project – it’s going to happen , clients (paying for the code) have the right to change their mind , accept it and get on with it.

• Agile Family Includes

  • XP (Extreme Programming)

  • Scrum

  • Adaptive Software
    Development

  • Lean Software
    development

  • Feature Driven
    Development

  • Crystal

  • DSDM

• Values
  wrap Principles wrap Practices

• Values
  (from the Agile manifesto)

  • Individuals and interactions over processes and tools.

  • Working software over comprehensive documentation.

  • Customer collaboration over contract negotiation.

  • Responding to change over following a plan.
    

• Principles
  (Customer Focused)

• Deliver early, deliver often.

• Deliver valuable software.

• Welcome change.

• One
  Big team (business people and developers)

• Principles (for Management)

  • motivated individuals give better results

  • face 2 face is the best way to communicate (although accept need to
    communicate across location and across time as good 2^nd
    best).

  • Remember : working software that meets business needs is the primary measure
    of progress

  • Promote sustainable development (or you’re just going into Technical Debt)

• Principles(for Teams)

  • use technical excellence and good design to promote agility but

  • simplicity is essential

  • the best architectures, requirements, and designs emerge from
    self-organizing teams (rather than imposed from above)

  • do continual improvements to the process

• Practices

  • Continual Improvement

  • Technical Excellence

  • ProjectManagement

  • Business Practices

  • Community and Collaboration

• Why Agile

  • Waterfall projects : we’re most likely to find bugs in testing phase at the
    end , when (a) we’re most likely to be under time pressure and (b)
    when they’re most expensive to fix.

  • Waterfall projects: Hard to know how far through we are , as each step is
    different from the last (design has gone well , but will coding do
    better or worse?)

  • Agile:Testing is continuous, so likely to get early feedback and
    resolution of bugs. Testing = Unit Tests and Acceptance Tests.

  • Agile: Progress is steady and measurable , as we carry out all
    tasks as part of a regular cycle.

  • Productity = doing less but producing more value. e.g. Customer can prioritize
    highest value tasks and we deliver these first.

  • Standish group stats showing small projects are more successful.

  • Deploy early and often gets usable software into the hands of users sooner
    where it can start to payback it’[s investment earlier.

  • Success factors for Agile projects:

• Enthusiastic development team/ Committed customer / Knowledgeable on-site QA
  resource / Didn't cherry pick practices / Open workspace / Regular
  retrospectives.

• Still hard work to do:

  • Good people give good software

  • Can be faked , so people really need to buy in

  • Practices are learnable / a lot are common sense

  • Recognize reality

Informative
Workspace

• Person walking into 'normal' coding office has no idea of what is going on, nor what status it is at. Most of the stuff is in people's heads.

• Informative workspace seeks to communicate this information (via simple methods)in the office e.g. Notice boards, coder of the week hat , printed graphs of velocity , iterations etc.

• Kent
  Beck : "An interested observer should be able to walk into the team space and get a general idea of how the project is going in 15 seconds. "

• Similarto Kanban idea – while going for Just in Time / continual improvement , visual representations are displayed to demonstrate
  progress.

• Information Radiators : anything that gives out info (example given of monitor running , showing latest build progress).- jokey examples of Lava
  Lamps / notes in toilet

• Toyota (Toyota production system – recognise their edge is in how they build their cars, and not just the cars that they build).

  • Human face to automation.

  • Board giving current
    production status

  • Audible Cues

  • Ability for anybody to stop the line.

Testing and Design by Contract

• Started by Bertrand Meyer in the Eifel Language

• Frameworks available to add these (fully) to the Java Language – over and above the functionality available in Java 1.4 (the assert keyword)

• Already have a contract that is enforced by the compiler in Java (e.g. Method signatures , return types)

• Adds to this , to be a finer grained level .e.g method should return not only an Integer , but an Integer of value 0 to 100

• Like every contract both sides (Caller and Callee) have responsibilities

• Pre Conditions : Condition that must be true when the method is called.

• PostConditions: Condition that the method guarantees when it returns

• Class Invariants state what will be true at a class level (once all pre-conditions at method level / constructor level satisified)

• Both pre and post provide additional specifiication (.ie. It is clearer to people using the code what is required / what it does). As such
  provides clearer design and additional documentation.

• Can make code more succient by replacing 'boilerplate' code with standard check (e.g. Precondition param must not be null).

• Java
  Example :

  • Pre
    Condition /** @require !empty() */ - as
    javadoc on method (multiple checks allowed) –

  • Post
    Condition : /** @ensure !full()*/

  • Class Level invarient: /** @invariant 0 <= count()*/

• Exceptions

  • Pre Condition violation should give RuntimeException – provide method to test before call (e.g. IsEmpty() before doing remove)

  • Post conditions: supplier should be every effort to fulfill these : so if it can't , it is normally due to an Exception (callee should be prepared for this failure)

• Junit

  • Codein Junit verifies the contact of the class (and provides documented example of code use)

  • assert methods = post condition testing

  • test invarient by checks at class and not just method level (e.g. Check overall status of class, not just return value of method under
    test)

  • Pre conditions by be tested by violating these in setup (code before call to method/ class under test) and ensuring exception is thrown.

• Think about Test as a contract.

Acceptance Testing

• Acceptance Tests – defined (or agreed by customer) , states thatfunctionality is complete

• Differ from unit tests in that they are system wide rather than at class/unit level.

  • Sometimes people used high level / coarse level Junit tests.

• Unlike unit tests don’t need to be a 100% all the time (but once passed , should alway pass)

• Automation is nice (for developer and customer)

  • Own note: Not everything in acceptance testing is automatable. e.g. UI testing.In this case automating the acceptance testing of the calculations (the 80%) means that the UI testing is a lot easier.

• Sample Frameworks for Automated acceptance testing

  • FIT – see notes below

  • Exactor – see notes below

  • Fitnesse – FIT but wiki based (easier to do multiple tests , easier to communicate these to a team.

  • WinFIT runner

• Inputto all these tools is close to a spec (close in that typicaluser , after one walkthrough should be able to understand what the documents mean).

• Tests can be written before application is build (again, the notion of the tests forming a spec). A lot of the commerical tools ,
  especialy those that record against a ‘live’application, do not allow this.

Automated Acceptance Testing with FIT

• FIT
  - http://fit.c2.com- Framework for Integration Testing

• Allows Customer s to review (if not write) the acceptance tests.

• Previously would have done these tests manually , or via large Junit tests (i.e. Use Junit not as Unit testing , but a way of describing the entire app from the user point of view).

• Data (unlike in Exactor) is specified as a HTML table. All non-tables are ignored (so safe to created tests documents using MS Word).

• Fixture (connects this HTML Data) to run test against 'production' code.Fixtures are written by programmers (as part of proving code meets
  the spec). Three types of fixtures.

  • Column

    • One class for each table

    • Fit works through on a line by line basis – good for repeating the same action over and over again.

    • 1^st Line of Table : Class Name to be tested

    • 2^nd Line of Table : class variable or methodName() to be set / called

    • 3^rd –
      Xth lines of table: values to set or expected values to be returned

    • Good for testing Domain (Business) Logic parts of an application

  • Action

    • mulitiple class for
      each table

    • start – the class to be tested

    • enter – value to be passed into method (no return value)

    • press – call method (no input or output)

    • check – check value on method (no input)

    • Good for stimulating interaction with the user interface (or more accurately either the controller that sits just behind the user interface).

  • Row

    • Like Column , but interprets all at once (rather than one at a time)

    • extend RowFixture ,
      provide query[] and getTargetClass() methods – allows Fit to see what data structure

    • good for testing coding in the service / persistence / db layer of code.

Automated
Acceptance Testing with Exactor

• Exactor (http://exactor.sourceforge.net)
  

• Allows Customer s to review (if not write) the acceptance tests.

• Previously would have done these tests manually , or via large Junit tests (i.e. Use Junit not as Unit testing , but a way of describing the entire app from the userpoint of view).

• Comprises (like fit) of

  • Script – a text file thatyou could show the customer.

  • Commands : what the script calls , extends Exactor classes. These commands then call the code beingtested.

  • Command extends Junit assert –
    so usual capabilities available.

  • Command provides access to test wide map to allow storing / exchange of values.

  • Allows composites to reuse scripts.

  • Scripts allow placeholder parameters

More details (including the slides themselves, as a preview of what you are missing) are available here in powerpoint, openoffice, pdf and flash formats. The slides explain how 4 pictures of bridges can explain the difference between Ad-Hoc , Predictive, Agile and XP projects. No , really , you do want to check this out.

Links to a lot of the sites / articles / tools used in the presentation are here on Del.icio.us. More posts on this blog about using agile techniques on projects are here.

The Bridges are:

• Old Drogheda Bridge from the 1200’s – Quick and Dirty or Ad-Hoc project. Got the job done , and fast . Was patched a load of times, but eventually fell down under the weight of the traffic.
• New Drogheda Motorway Bridge – Predictive Projects. Very easy to specify what you want (I want a bridge going from A-B to carry a motorway) and very easy to know when you are finished.
• Drogheda Railway Brigde – Agile. Once the longest Iron Girder bridge in the world.Built in the 1850’s and the spec has kept on changing since. This included a complete rebuild in 1925 without losing a single days traffic. How’s that for unit testing?
• Bungee Jumping off bridge in Queenstown – Extreme Programming (XP). Great fun if you’re doing it (and can be pretty effective), but scary for anybody watching.

As a sample of some of the pictures (which include lego people showing everything that can go wrong on a team), check out the image below.

.
Image from
TheBrickTestament.

Ironic then , that I’m meant to be presenting on Agile Software to the Irish .Net Developers Alliance (INDA) the week before -:-)

After a suitable pause , I’m now thinking of starting work on the next version of NoUnit. Some of the features I’m thinking of including are:

• Eclipse Plugin , so that you can run NoUnit code coverage reports as easily as you do JUnit tests in Eclipse.
• Support for JUnit 4 and Java 1.5 Annotations
• Support for EJB 2.0, EJB 3.0 and Spring – currently NoUnit only shows direct calls between Java classes.
• Various outstanding bugs and change requests from users.

Is there anything else you think should be included? Leave your comments here.

After a suitable pause , I’m now thinking of starting work on the next version of NoUnit. Some of the features I’m thinking of including are:

• Eclipse Plugin , so that you can run NoUnit code coverage reports as easily as you do JUnit tests in Eclipse.
• Support for JUnit 4 and Java 1.5 Annotations
• Support for EJB 2.0, EJB 3.0 and Spring – currently NoUnit only shows direct calls between Java classes.
• Various outstanding bugs and change requests from users.

Is there anything else you think should be included? Leave your comments here.

The presentation is due to be made on the 7th March to the Irish .Net Developers association at Buswells Hotel in Dublin.

Take a look at the presentation (in progress), and leave comments here with your feedback!

Metrics

1. Use Cases Completed (e.g. Track using XPlanner)
2. Tests (Junit) written to confrim that these use cases are complete.
3. Percentage of Unit Tests Running (should be 100%)
4. Code Coverage of these tests (using NoUnit)
5. Code Quality (Sun Javadoc Quality Checker, Code Review)