VS.Net TestProject - Can anyone point me at a good beginners tutorial.

[FunkyDexter]

Hi Guys

First a bit of background: I manage a small (6 people) development team working directly for a client (ie, not a software house). Traditionally this team has hacked it's way through any code changes. We don't have a testing team so each dev tends to unit test their change manually and then shove it out into production. Needless to say, we introduce bugs like it's going out of fashion and I'm sick of looking stupid. I believe (but am open to alternative suggestions) that the way forward is for us to start using test projects in the app and taking a more TDD aproach. As the suite of tests builds up we'll know if the change we're making is shafting something else that it shouldn't be. I'm therefore trying to get my head round how to set up and use test projects.

I'd love to find a tutorial on this but googling is mainly returning me high level 'how to write good unit test' stuff which is kinda the next step for me. I need to get the actual mechanics right first and I'm struggling to find anything that walks me through that. If anyone could point me at a resource I'll be over the moon.

[Hack]

What do your developers use for specs? Who writes them? (If you don't have written specs, test plans don't mean bo diddly)

[FunkyDexter]

Hi Hack, thanks for the reponse.

To be honest, I'm not too concerned about that at this stage. Don't get me wrong, I would dearly love to get some formal process implemented here but politics and ego have tended to prevent me from changing the bad practices that have existed here since time immemorial. Don't get me started on how frustrating that has been but some of the folks that have driven that view point have recently gone so things are finally starting to change a bit. The shift will be gradual so I've got to pick the areas I push with care to get the most benefit, both percieved and actual.

Anyway, until recently project planning and speccing were deemed to be unneccessary faf and representative of an IT department that had ideas above it's station... or something like that. Thankfully that's something I have managed to change and we're now knocking up more specs than superman working at an opticians. Part of the spec is the tests that the developers deem necessary (our developer liaise with key users in the business and do their own specs - we're not an IT company and don't have the luxury of consultants or analysts) and we also allow the key users to add any tests they want. I should say that I'm not fooling myself that this represents a proper test driven aproach and the tests certainly won't be 'unit' tests.

What I'm hoping to achieve in the short term is that we write some high level tests for any changes we make. E.g. We normally brochure prospective customers then phone them. Under some conditions (ie internet enquireies) we don't want to wait for the brochure to be sent before we pick up the phone. There was a problem where, if the call generated an appointment before the brochure was sent, the brochure got cancelled. I fixed that bug personally. 3 months later the bug was back because someone (don't know who) has made a further change that has knocked mine out. That's the sort of thing that happens frequently and makes us look stupid. It shouldn't be beyond my wit to write a test that enters a customer, chuckes them into marketing, marks the call as made, generates and appt then makes sure the brochure still shows as due. If that test had been in place we could have picked up on the fact that a subsequent change had broken it. I imagine a similar process with new requirements. Essentially, I'm looking to semi-automate a system test we can run before any roll out.

Anyway, that's the idea, but I'm struggling with a few of the mechanics of using test projects. Like, can I halt the code with a breakpoint in the test code - I can't seem to get that to work at the moment which is making the test itself hard to get right.

[abhijit]

There is a channel 9 video on this.

[FunkyDexter]

Thanks for the response Abhijit. Annoyingly, I couldn't get the video to run but I'll try it again from home tonight. I'm not sure it's what I was asking for (I'm really after the ide stuff around standard tests) but, happily, it does look like something else I was starting to wonder about: UI Testing. I hadn't worked out how we were going to do that yet so this video will probably be a God-send.

Thanks

[abhijit]

All our efforts to automate testing so far have failed irrevocably. Mainly due to the nature of our systems (Powerbuilder / VB 6.0). When we moved a lot of development to Java & C#, I see testing being done in the same haphazard fashion.

If your IT department is driven by the business, your first goal is to make it working. Everything else sits on the back burner till it becomes absolutely necessary. Sadly I don't see that happening with automated testing.

[FunkyDexter]

If your IT department is driven by the business, your first goal is to make it working. Everything else sits on the back burner till it becomes absolutely necessary

Yeah, that's been a big problem in the past. Thankfully the board are starting to see that a more methodical aproach would probably benefit us and I'm finally getting to spec everything up, get it signed off and we're now getting time to test before rolling changes out. Basically they've lived with the pain of botched change management and roll outs for long enough to start recognising that some extra time spent doing things formallay up front is probably going to save alot if time fixing all the problems after the event. Of course, if there's something business critical that's not functioning then process'll probably still go out of the window while we fix it but I guess we'll just have to live with that.