Platformability is now optimised for Portable Devices.
(Give it a go on your mobile!)

How to achieve a better User Experience on Portable Devices…
(More …)
Platformability is now optimised for Portable Devices.
(Give it a go on your mobile!)

How to achieve a better User Experience on Portable Devices…
(More …)
When tests are small, a test failure means just one thing – somewhere in these ten lines of code which are being tested, there is an error. Ok, sometimes this can mean that there is an error in the test script, or a there is a failure, or change of expectation, but fundamentally, it pin-points the cause of the failure to a small target, which usually means that debugging becomes trivial.
When an end to end acceptance test fails, the failure could be due to any one of a large number of source lines or expectations changes across a large body of code. Debugging may be quick, but often isn’t.
The nature of agile projects, with lots of small releases mean that there are a lot of test runs to execute if you want to have any confidence in the code and the product.
Ignoring this testing just generates projects which will fail – not may fail – will fail, categorically will fail!
There are two sets of tests that are critical here…
Good unit test coverage and a TDD approach to development ensure that the rest of the organisation is supplied with product that works as developers expect it to.
Component tests and functional acceptance tests ensure that the product does what the product owner expects it to.
Without these tests in place, iterating quickly places an impossible to meet burden of verification demand on the testers and product owners, which just gives you a fragile process not an agile one.
Is your process Agile or Fragile?
The Observer design pattern is used in many applications. If you are unfamiliar with it, or need to remind yourself about the specifics, you can read about it at Wikipedia or MSDN. Caplin Trader even provides a helper class to take care of a lot of the boiler plate code: caplin.core.Observable.
The purpose of the Observer design pattern is to allow one object to notify other objects of events – usually to do with changes to its state. One common problem I have encountered however is what to do when an Observer is first registered, since the object that it is observing may already be in a particular state.