I\'m the lead programmer at a small software firm (currently 4 developers includ
ID: 643876 • Letter: I
Question
I'm the lead programmer at a small software firm (currently 4 developers including myself), we develop bespoke ASP.NET WebForms applications for businesses. I joined there in 2010 just after graduation, so it was my first real job. After more senior programmers left, I was promoted to lead and we hired a bunch of junior devs for me to mentor.
My issue is that currently, we have a huge amount of work from delayed projects (some 2-3 years delayed) so our development is very rushed and testing is left to the very last minute, and our releases often go out with obvious bugs we should have picked up. This really brings down morale and gets everyone very stressed, including myself.
We have no testing framework at all, or barely even any organisation to what we're meant to be doing. We never use unit tests, and all testing is manual and very laborious. This sort of methodology is all I've been exposed to since becoming a programmer, but I'm fast learning that this is not how a software house should work.
I've been trying to familiarise myself with TDD and Unit testing, but it's all extremely foreign to me and I'm having a hard time visualising how we could actually use these in our applications. Most of the logic inside our apps are in the code behind for each page (something I am now pushing to get away from) and from what I've read this makes testing much more difficult.
Does anyone have any advice, or know of any good tutorials, that'll help us get up to scratch with TDD?
We have a lot of other issues, including not using SVN efficiently, having a very basic HelpDesk for our bugs and giving our team fairly vague specs. Again these are things that I want to learn myself, but I'm needing to spend a lot of time actually teaching myself all of this. So if anyone has any advice for this I'd appreciate it but our testing is the most crucial thing right now.
Explanation / Answer
I'm in a similar place, so I can't offer the best help, and I'm eager to see the other answers.
But I can enthusiastically recommend Roy Osherove's "The Art of Unit Testing." It's focused on .NET and will give you plenty of ideas for what you should be aiming for in Unit Testing.
From what I know so far, you are right to be pushing the code to central classes, and out of the code behind. I'm working towards a more centralized architecture with better separation of concerns, similar to that encouraged by MVC. (Maybe worth some time looking at MVC just to get familiar with the architecture. Won't hurt the resume either.)