March 31, 2006 Leave a comment
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:
Framework for writing automated unit tests (don’t need to use Junit
to write the tests , but it helps)
tests extend TestCase
test methods (pre Junit 4.0) : public void testSomething() method
assertEquals assertTrue assertFalse assertNull assertNotNull
assertSame and fail methods for testing.
tearDown() methods called before and after each test method.
(groups of TestCases) replaced by Ant and (Eclipse) IDE
Run tests via
built in Text / Swing test running , or more likely use IDE / Ant
same or paralell folders
Mock and Stubs
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?
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).
expensive to create objects
create all objects that production code interacts with.
middle and develop outwards
can ripple out / appear elsewhere.
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.
like stubs, except that they are intelligent enought to self-verify.
Secondary objects (normally ones that we build) instead of API (as
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
tend to test more the interaction between objects rather than a unit
test of the object itself.
than mock external API’s
Smells and refactoring.
are bad or suspect design decisions in code.
bad , but should be looked at (often will involve a trade off)
often hard to understand , hard to change code.
duplication / long methods / poor naming / tightly coupled classes
/ switch statements /
Small , controlled changes to codebase , so that it continues to
compile / tests run to improve the design. The behaviour remains
exactly the same.
refactoring and adding additional functionality.
automated tools and Unit tests to confirm that nothing has broken.
!= Rewrite. Codebase is evolved , not thrown away.
In some ways
, equivalent to Use Case from Predictive methods (but with subtle
chunk of functionality that makes sense to the customer.
represented as card / conversation / paper based documents (more
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.
importance of requirements
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
should be Invest:
(FlashCard , as used by Xplanner)
Be careful of
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.
should give us the acceptance tests