June 21, 2009
ASP.NET Unit Testing
Considering that the project that I mentioned in the previous post was developed for a real-world company (MDevices) and that it was developed for a discipline at the College of Engineering of the Oporto University (FEUP – Faculdade de Engenharia da Universidade do Porto), we had some rules that we had to obey. One of these rules, established by the professors requirements was to produce a test report for the application, which had to include Unit Tests.
However, we have faced a major problem. As we had used Server, Session, Request and Response objects, the Visual Studio 2008 unit testing platform just wouldn’t run. Why? Because apparently, although it was developed to perform unit testing on every kind of .NET projects, it didn’t run in a server context. What does that mean? We wouldn’t have access to server-specific stuff like Server, Session, Request, Response, Cookies and so on… I have searched throughout Google and MSDN just to find out that it just wasn’t possible. Some workarounds were available, which involved editing the web.config file, and I tried each one of them. Nothing worked. So, as the time disappeared, a differente solution had to be found. I tried using some other unit testing platforms, such as NUnit (which also did not contemplate web-based software) and NUnit-ASP which is now a dead project. Resharper looked like a good option at the start, but the very same problems appeared not long after the installation of this addin.
So, to solve this problem, I started studying the Visual Studio Expansibility API and developed a small Unit Testing Add-In for Visual Studio 2008. Based on some examples which I was able to find with the help of Google, this Add-In was quickly integrated with Visual Studio 2008. The big problem was to access the project and its contents. Google did not know too much about this, and it looked quite clearly that MSDN did not want us to know anything about that either. With some effort and a lot of time spent with trial-and-error, I discovered a way to access every solution item and through Reflection access its contents.
Ok, so I had the whole code available. What would I do with that? How could I test that in a server context? The idea was quite simple… My Add-In generated automated unit tests for each of the code files that the user chose and saved them in a new class file that was added to a new folder inside the solution. After that, it generated an .aspx and its code-behind files, which has a simple task: Call every test-class function, perform the tests and present the results.
So, when the project is launched, the Visual Studio’s Web Development Server would launch and we would have the server context that we needed. After that, it was just a matter of navigating to the generated folder and open the .aspx file contained within. It would show up in a new webpage the result of running all of the tests, because now it would run within server context! Of course that these automatically generated files could (and should) be edited, in order to suit the programmer and testers needs. But nevertheless, with this project, my team was able to save a large number of hours of work!
I will make this Unit Testing Add-In available, as soon as I make it prettier. It looks quite rough now, although it is totally functional! News about this project will become available in this blog very soon (I hope!), so keep visiting! 😀
Tiago Fernandes 