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:
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