My mission to introduce automated testing at work is now finished. It is far from complete, but today was my last day there. In a couple of days I'll be working for another employer.
It seems I managed to plant a seed of interest in testing; some (now past) colleagues told me they are sorry that I didn't get further in introducing some tests and the testing process. That makes me feel that they have actually understood the importance of testing, but it also suggests that no one feels confident enough to continue the work on their own.
Then again, it's out of my hands now. I guess all I should be interested in is that my new employer is excited about agile development.
Friday, October 06, 2006
Friday, September 01, 2006
Old Habits Are Hard to Break
In the last two weeks I've spent some time writing a small program, which I finished a couple of days ago. It served its purpose but looking back, I see some room for improvement.
First, the GUI was a crucial part of the program, and I am still to learn automated testing techniques for user interfaces, so I didn't go far tests-first. Instead of learning to use the appropriate tools and techniques I decided to go on without (GUI) tests.
Second, since I didn't know how to write good tests for the interface, I started slacking with writing tests altogether. When I was running out of time, I also reverted to the "good" old cowboy coding style.
Third, I tried to write the program one feature at a time, using a simple planning game by myself (me being the customer as well as the software provider). I made some time estimates and decided on the next features to write based on the available time. I guess I could have prioritized the features in a different way, but I did get a working piece of software in the end - with the chosen features done to the end, and the rest missing completely. However, my accuracy concerning the time estimates varied a lot. I also think I could have adjusted my time estimates better based on the time I used while implementing the previous features.
And last, I actually noticed all of these issues already while writing the program but didn't "have time" to correct them. I guess this way of thinking is the first thing I should change. (This might be closely related to reverting back to the old coding style, but deserves to be mentioned separately.)
Still learning, I guess. But then again, aren't we always?
P.S. Two co-workers returning from their holidays commented on my unit testing paper. One of them was impressed by the detailed instructions I had written. The other - the head of our C# development, kind of - asked where I got the idea and started chatting with me about automatic builds - of which I didn't write much in the paper... I guess there might be a breeding ground that I was unaware of for some agility.
First, the GUI was a crucial part of the program, and I am still to learn automated testing techniques for user interfaces, so I didn't go far tests-first. Instead of learning to use the appropriate tools and techniques I decided to go on without (GUI) tests.
Second, since I didn't know how to write good tests for the interface, I started slacking with writing tests altogether. When I was running out of time, I also reverted to the "good" old cowboy coding style.
Third, I tried to write the program one feature at a time, using a simple planning game by myself (me being the customer as well as the software provider). I made some time estimates and decided on the next features to write based on the available time. I guess I could have prioritized the features in a different way, but I did get a working piece of software in the end - with the chosen features done to the end, and the rest missing completely. However, my accuracy concerning the time estimates varied a lot. I also think I could have adjusted my time estimates better based on the time I used while implementing the previous features.
And last, I actually noticed all of these issues already while writing the program but didn't "have time" to correct them. I guess this way of thinking is the first thing I should change. (This might be closely related to reverting back to the old coding style, but deserves to be mentioned separately.)
Still learning, I guess. But then again, aren't we always?
P.S. Two co-workers returning from their holidays commented on my unit testing paper. One of them was impressed by the detailed instructions I had written. The other - the head of our C# development, kind of - asked where I got the idea and started chatting with me about automatic builds - of which I didn't write much in the paper... I guess there might be a breeding ground that I was unaware of for some agility.
Tuesday, August 15, 2006
Work update
Since my last post I have tried using VS2005's testing framework and NUnit with our actual code base. Yesterday I checked in the first tests (totalling 38 test methods for a single class) to our source code control. I had picked the class under test quite randomly but hit a sweet spot with my choice - one of the tests found a bug in a method that was written more than three years ago. And I actually tried to write the tests to match existing code... Perhaps the method is not used very much, since no one had noticed the bug before. (It should have turned up by now, because the method generates a short part of an SQL statement, and with one valid input it returned SQL that is not valid in any DBMS.) There was also at least one method where a null parameter was not considered a special case.
"The other guy" tried checking out the tests and running them, and everything went smoothly. He also thought the tests were a good example of finding small bugs in existing code. Since everything had worked, I updated my paper and added some technical details about running the tests.
Today I finished writing it (at 19 pages) and checked it in. I also wrote tests for another of our basic classes and checked them in as well. This time writing 24 test methods took a lot less time than the previous ones.
So far no one has commented on the work - except for the guy who wrote the method with the bug I found. I went to check if it was ok that I used his method as an example of hard-to-see bugs that could be found easily with testing. He was just browsing through my paper and was pretty impressed. Although no one else has given any feedback, I feel pretty confident. I actually think I'm changing things here.
Let's see if I'm just fooling myself or if my colleagues also start writing some tests.
"The other guy" tried checking out the tests and running them, and everything went smoothly. He also thought the tests were a good example of finding small bugs in existing code. Since everything had worked, I updated my paper and added some technical details about running the tests.
Today I finished writing it (at 19 pages) and checked it in. I also wrote tests for another of our basic classes and checked them in as well. This time writing 24 test methods took a lot less time than the previous ones.
So far no one has commented on the work - except for the guy who wrote the method with the bug I found. I went to check if it was ok that I used his method as an example of hard-to-see bugs that could be found easily with testing. He was just browsing through my paper and was pretty impressed. Although no one else has given any feedback, I feel pretty confident. I actually think I'm changing things here.
Let's see if I'm just fooling myself or if my colleagues also start writing some tests.
Subscribe to:
Posts (Atom)