Fabulous! I have never known a project with so few bugs! As a new convert to the TDD fold, I feel that I am quite often evangelising at my collegues on other teams. This must be terrible for them - I can see their pained expressions, but the phrases keep tumbling out, no matter how much I try to keep quiet
"It's sooo much better writing the tests before you write the production code..."
"We have 5 times less bugs raised per day in this project than any other project I have worked on..."
"The project manager loves having builds that 'just work'!"
And so it goes on. The poor devils. I think many of them actively avoid me and my team now, so that we wont try to spread the good news anymore. (I'm starting to understand thep ain suffered by the Jehova's Witnesses as they try to convert me quarter on quarter).
But I understand completely why my collegues are so sceptical. They exist in the old world. The old world of programming is a world of pain and fear. Life is hard and bugs creep out when the test engineers shine the lights of the system test under the chassis of the code. Assuming that the bl**dy kit installs correctly in the first place. They don't have time to write tests, ironically because they are spending too much time fixing up existing problems. It is a vicious circle of the cruellest kind. Witness the reasons for not adopting TDD
- My team doesn't practice TDD. I wont get my work done if I start wasting time on unit tests.
- My code works already. I'm wasting my time writing tests.
- I'm changing an old set of classes. The original code was not under test, so I cannot start to test it now.
- I've got to get this done NOW! I can't waste time writing tests - my boss will kill me.
However, we are slowly starting to make progress with a few of the more enlightened engineers in other teams. There will be no revolution at my workplace, but a lot can be achieved through baby steps. I was chatting to a collegue the other day about general techie stuff. He has finally started to write some JUnit tests for his new code. This is good stuff, and I enthused at him, keen to see how far down the path he had journeyed.
"Are you writing the tests first?", I asked (without a great deal of hope, it has to be said).
he answered, with a wry smile "I can't write the tests until I know what my class does!".
It's funny how the TDD community sees the world differently. I bit my lip. now was not the time. All I need is a day or 2 pair programming with him....and then we can prove to the world that viral marketting really doesn't work ;-)
technorati tags: TDD
I could pick out a pheasant from a field full of worn socks, but does she want me to work? No. All she wants me to do is sit still and look into this silly shiny box of hers.
I expect she'll want me to lie down in the mud next....
¶ 12:33 PM 0 comments
Scott Adams is giving away free versions of his book 'God's Debris'
http://www.andrewsmcmeel.com/godsdebris/
¶ 5:22 AM 0 comments
We have a number of .NET objects in our legacy code which load in configuration from app.config files. This can be a bit of a problem when you want to get a class under test - as you almost certainly want to reconfigure the object in more than one way.
For example I have a class
using System.Configuration; |
To break this dependancy you should create a new constructor which accepts a name value collection. Move the logic into this new constructor and then replace the static calls to AppSettings with calls to your new input variable.
using System.Collections.Specialized; |
The great thing about this approach is that the behaviour of the class has not changed. This is important, because your class is not under test yet (but it soon will be!). Now you can put the class under test without needing app config files.
A word of warning. You must be careful and check for subsequent calls to AppSettings in other method calls. If other methods use the static method call, then you will need to either hold a reference to the configuration parameters and use this later on, or else change the behaviour of the class to setup what ever the methods initialise in the construction logic.
technorati tags: Refactoring, TDD, C#
The following code snippet will search for connections by the user 'fred' and will kill them by SPID.
declare @spid varchar(10)
declare spids cursor for
select convert(varchar, spid) from master.dbo.sysprocesses
where ecid = 0 and loginame='fred'
open spids
while(1=1)
begin
fetch spids into @spid
if @@fetch_status 0 break
print 'Killing spid ' + @spid
exec('kill ' + @spid)
end
deallocate spids
