I have recently completed a large financial system that comprises of many Web Services.
If a particular component needs to communicate with a Web Service it does so via a proxy class. So is the target Web Service was named something like StockPrices. The proxy would implement an interface such as IStockPrices. Using dependency inversion, the IStockPrices would be one of the parameters on the constructor of the calling client.
This allowed us to use mock and fake IStockPrices during testing. Thus we could test various failure conditions in the target Web Service
Please contribute to this article describing various integration testing techniques that you have used.
11 May 2008
26 April 2008
Fixing bugs in an Agile environment.
The testers or users have reported a bug in an application that has been written using TDD. How do you go about fixing the bug?
Here’s what we do. Create a normal User Story about the bug. It will be prioritised and estimated on in the normal way.
Because we all know the application, we can quickly identify the offending class and usually the exact method that will be causing the problem.
Here’s an example of a bug, “I entered two amounts of 100 and 160. I had set the tax rates at 20% for any amounts less than 150 and 25% for amounts of 150 and above, I would therefore expected the result to be 320. The screen result actually displayed 312.
Based on the details in bug report, we create a failing test (same sort as used during TDD), to confirm the findings of the tester. The test will fail with something like: “Expected 320, actual 312”.
Now that we’ve got the failing test we can get into the actual code and fix the bug.
We name the test so that it includes a bug reference. Such as:TestTaxCalculator_Bug123_DifferingTaxRates()
The test becomes part of the part of the suite of automated tests that are performed each time on a check in.
When we update the bug report, marking the bug as fixed, we will included a reference to the test such as “Please see test TestTaxCalculator_Bug123_DifferingTaxRates()”. This gives an audit trail and helps other Developers if something related to the bug occurs.
As a team we will then discuss how this sort of bug occurred. How was that set of conditions not covered during normal TDD? What can we do to prevent similar bugs?
At the time that the bug is fixed, the developer(s) should check all the other tests that cover the offending method and review any assumptions in those tests.
Here’s what we do. Create a normal User Story about the bug. It will be prioritised and estimated on in the normal way.
Because we all know the application, we can quickly identify the offending class and usually the exact method that will be causing the problem.
Here’s an example of a bug, “I entered two amounts of 100 and 160. I had set the tax rates at 20% for any amounts less than 150 and 25% for amounts of 150 and above, I would therefore expected the result to be 320. The screen result actually displayed 312.
Based on the details in bug report, we create a failing test (same sort as used during TDD), to confirm the findings of the tester. The test will fail with something like: “Expected 320, actual 312”.
Now that we’ve got the failing test we can get into the actual code and fix the bug.
We name the test so that it includes a bug reference. Such as:TestTaxCalculator_Bug123_DifferingTaxRates()
The test becomes part of the part of the suite of automated tests that are performed each time on a check in.
When we update the bug report, marking the bug as fixed, we will included a reference to the test such as “Please see test TestTaxCalculator_Bug123_DifferingTaxRates()”. This gives an audit trail and helps other Developers if something related to the bug occurs.
As a team we will then discuss how this sort of bug occurred. How was that set of conditions not covered during normal TDD? What can we do to prevent similar bugs?
At the time that the bug is fixed, the developer(s) should check all the other tests that cover the offending method and review any assumptions in those tests.
17 March 2008
Sludge methodology
I have recently been working as a Developer in a large organisation, more than twenty thousand employees. They develop software using the Sludge methodology. It's a lot like Waterfall, but instead of water, mud is used! It's so slow. It wastes millions of ££££s, and the end result is not what the users want. It's painful to watch and be involved with.
I was wondering if anyone has worked in a large company, greater than twenty thousand employees, where a project has been implemented using an Agile methodology? How did you go about it? How did you overcome the natural resistance to the word Agile that seems to exist in large companies?
I was wondering if anyone has worked in a large company, greater than twenty thousand employees, where a project has been implemented using an Agile methodology? How did you go about it? How did you overcome the natural resistance to the word Agile that seems to exist in large companies?
Subscribe to:
Posts (Atom)