Understanding unit tests/TDD for ASP.NET webforms [closed]

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.

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.

Filed under: softwareengineering - @ 14:05

Thẻ: asp.net, c++, tdd, testing, unit-testing

Thiết kế website giá rẻ

Danh mục

Understanding unit tests/TDD for ASP.NET webforms [closed]