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.)

First of all, you definitely shouldn’t feel bad that you’re having a hard time getting to grips with this. WebForms is not a framework that was ever designed with testability in mind, and it certainly doesn’t do anything to make itself easy to test.

The first and most important thing has already been mentioned in Jamie F’s answer – you need to ensure that as little code as possible is in the .aspx page’s codebehinds, and as much as possible is in separate business logic classes. The code in the codebehinds should be just wiring up the ASP.NET controls to and fro, and very little else. That way, you can start to get some unit tests around existing business logic and develop new business logic using a TDD approach.

For the actual web interface, you’re probably better off looking into some browser automation testing framework – WatiN and Selenium are two that leap to mind. How to take a TDD approach to browser automation testing, though, I do not know. These techniques are, to my mind, much better suited to setting up regression tests after development is finished.

As others have written, web forms was not developed with testability in mind however you can make your life a lot easier by learning patterns such as MVC, MVP and MVVM. Web Forms in particular plays quite well with MVP.

Dino Esposito has a great article here on MSDN about using MVP with web forms. You can also look at ASP.NET MVC which was built from the ground up taking into account dependency injection, inversion of control, testing, etc.

You essentially need to ensure the cleanest separation of concerns. Try looking into Aspect Oriented Programming to formalise this. By enforcing a separation of concerns you make it far easier to unit test, do dependency injection, and all the things you need to do to make testing simple. I’ve used Spring in Java, and they have an AOP module which is also in Spring.NET, it might be worth having a look at.

My suggestions are as follows:

• Componetize the application as much as possible.
• Do not mix business logic with display logic in web forms
• Look to a pattern such as MVP or MVVM for web forms
• Consider moving to ASP.NET MVC if it fits within your business goals
• Adopt dependency injection to decouple your application
• Write unit tests to test your code
• Use automation testing to test your interface

The reason I am suggesting MVP/MVVM is because these patterns will help to enforce a separation of your data model from your view and therefore help enforce a separation of concerns.

Good luck!

TDD is a paradigm shift, and is a type of testing. It also sounds like you would benefit from some general unit testing too, and maybe a couple new “policies” to which your team will adhere too. Couple things before you set out on the journey, make sure your team is on board, if they’re not, try to convince them with articles and demonstrations. Make sure you include them and get their feedback along the way.

TDD (Test Driven Development) is write the test first, then write the code to pass the tests. This has been proven to work well, and lots of people are behind it.. It’s probably easier to start a project with this type of strategy than to implement it mid-way through without a supporting code structure. There are many resources available out there on this.

Then you have unit testing, which in your case, is probably good to implement sooner than later. This type of strategy will just help you test your code. you write your code, and then test it (Arrange / Act / Assert). Unit testing just makes sure if you give the proper input, you get the proper output. Visual Studio had a testing framework built in, and XUnit is also a nice and easy testing framework to get started with and easy to implement.

I would start making it a practice to start developing in separate assemblies which can be referenced from the codebehind. That will create re-usability and will start towards a nice “layered” approach. Try to use good long naming conventions, and try to keep your classes organized and tidy. That shouldn’t get in the way too much of the existing development process either.

IMO, the next step would be to start identifying “behavioral groupings” out of the codebase and make interfaces out of them

• Isolate common methods within your applications which all pertain to
  a common idea.
• Create a class which implements that interface, and copy (cut actually) in the
  methods from the codebehind so that they implement that interface (then reference that assembly and replace the codebehind methods with your “new” ones)
• Eventually, you can start making some cool moves with those
  interfaces including easier testability (dependancy injection, IoC containers, etc..)

I think pulling out interfaces is a good place to start because it’s pretty easy with an existing codebase and the benefits of doing it are pretty high. here’s a good video which speaks to the subject (BDD?) Integration Tests Are A Scam.

Lastly, i would recommend the Team Foundation Service. Sounds like your team can get into the free version since you get 5 members free. This is going to help you and your team moving in an organized development direction as well as give you Source Control and a lot of other cool features like bug tracking, a “Big Board” (which is really cool), and a plethora of other good management tools which are useful for developers.

I hope at least some of this helps.. GOOD LUCK!

Brownfield Application Development in .NET

shows developers how to approach legacy applications with the state-of-the-art concepts, patterns, and tools developers apply to new projects.