Due to sickness, ill health and home equipment issues I have not been posting much of late. I have been doing a lot of reading though. In my literary travels I stumbled over this incredible posting that shows the kind of malpractice to which UK broadband services are subject. Many thanks to Andrews and Arnold ISP for the post I think I will switching ISP soon!
Mar
11
2010
11
2010
Feb
22
2010
22
2010
Five things – unit tests
Five quick points about unit tests that will reduce your defect rates.
- Always stop to add that simple unit test. You will be amazed how often this discovers a bug or unexplored corner case.
- Never develop from a main method, find a way to turn it into a test. Main driven development is horrible, they are not part of the continuous development cycle so once finished they get forgotten.
- Make all tests run in the continuous integration environment. A test that does not run is a dark test. Tests that are not continually run are probably broken. Same goes for main method development.
- Expend effort getting the time from commit to all project tests passing tests as small as possible. If I could check in, and see the results 1 second later there is little chance of me holding someone else up. Aim for less than 15 mins with current technology. Parallelism is the key. Separate the build, many small suits that run in parallel. Why not build a cloud just for running parallel test suits in?
- Do as much testing as possible using simple unit tests. Unit tests are cheap to write, run fast and are easier to maintain. Test as much as possible with them, resort to higher level tests only to test integration. Good unit level coverage will also mean the higher levels have less to do.
If you just did the above you would be doing very well indeed.
Some other test related thoughts I had today:
Why would you schedule your test runs on an hourly schedule? Always hook unit tests into the commit. If your unit coverage is high it might be possible to consider the unit tests a pass or fail threshold for a commit.
If you can’t fix a break quickly revert before the breaks pile up. Choose a source control system that makes this easy to do. The threat of a revert means people will go out of their way to test the build before checking in.
Integration tests should also be continuously run. There may be challenges, they are often slower, and more fragile. Break them into batches but not just by functional area. Consider batches split by test categorisation, with buckets like:
Slow running: Schedule infrequent runs.
Fragile but fast: Trigger on commit.
Performance: Run when system is not under load.
The general rule is be inventive, find ways to get them run as frequently as possible.
Finally ask yourself this next time you realise the need for another test, but decide not to write it. Why do I feel its ok not to write this test?
Too hard: Perhaps its time to find better ways to crack the problem. An opportunity to be creative.
Too trivial: It should not take too long to write it then.
Your under pressure to deliver: Local optimization, delivering untested code ultimately slows down delivery.
Happy testing!
Feb
16
2010
16
2010
Google Objects.equal, useful but be careful.
Google have a nice equals method to make boiler plate equals easier to read. Particularly good if you have many attributes in the method. http://publicobject.com/2007/09/coding-in-small-with-google-collections_8175.html
Be careful to check that your objects are consistent with equals though. I have mentioned this before.
Continue reading Google Objects.equal, useful but be careful. →
Feb
15
2010
15
2010
Scrum, where exactly do the managers go?
Goa State, India, Lifting the load: Martin Harris
Project Management Offices really serve no purpose in scrum. You are either a product owner, (not a manager), scrum master (not a manager either) or your in the team, (no technical leaders here either). So what about all that useful controlling and reporting stuff they used to do?
- Program management functions should be moved into the team.
- Team support comes from Agile coaches, or scrum masters. They are not managers, they guide and do not tell the team what to do.
- Responsibilities of release, budget, tracking reporting etc, are the Product Owners domain, once again the Product Owner is not a manager.
Its a bad idea to keep the PMO and attempt to re-brand it under Scrum. Keeping the unit and asking people to be scrum masters is a recipe for disaster. Its hard to change team culture over to scrum. Teams find it a big challenge to throw off the old and become self directed. If you have your old manager coming to your team the roles stay right where they were. So if you want to keep members of the PMO and they are technical, make them part of the team or remove them from the process.
Feb
11
2010
11
2010
When Change is hard
Just found out about Switch: How to Change Things When Change Is Hard – Chip and Dan Heath,
from some of the Lab49 consultants. I can’t wait to read it. Take a look at this clip:
The experiment in the hospital, reminds me of what happens when I am pair coding. When you are working in a pair, people are less likely to interrupt you. I think it contributes to the extra throughput for pairs. This book is going on my reading list.