Hugo Estrada's House of Wonder

I finally got the environment ready to be able to do Test Driven Development in Drupal.

Some quick thoughts:

1. Acquia stack is great to quickly setup a drupal environment. If you want to set up testing, then it sucks big time. Why? Because of what,, ironically, makes Acquia so cool: it has its own environment for drupal not connected with the rest of your computer. Cool because if you are working on windows, you only run the services when you need them. It sucks because when one attempts to run test on the command line or to use drush, it is impossible.

2. It makes programming feel like playing a strategy game. Big win here.

3. Amazing how many times it saves you from what would be very hard to track errors.

4. Running tests on the web interface is sloooooooow. I figured a way to use the time, which is to write the next tests, but I do feel that this is breaking the proper flow.

5. TTD is flow inducing, even with the problems in 4.

This was complicated to set up, but I am finally running a case. I may have to write a more detailed set of instructions on how to set it up on 6.x. The good news is that it is part of core on 7.

After doing some research, it seems that there is no clear way to unit test asp .net WebForms.

ASP .Net web forms behavior collides with the current testing principles. The big one being that you only test public methods. Well, it seems that most Web Form pages don't have ANY public methods, making it impossible to test following the unit test principle. For those developers that want to do testing, it means that they have to expose the different private methods that they are using as public methods, breaking a big principle in OOD, which is that public methods are the interface to the object. So the developer who wants to unit test their code either breaks the principle of not testing privates or breaks the OOD principle of exposing as little interface as possible.

So the solutions that I have found either involves some complex code bending to allow for the testing of private methods, doing weird practices such as exposing private methods as public.

The other big solution seems to be to move to the MVC framework. Ideal solution for new projects if one has the time to learn the framework, but won't help that much if one has to work with legacy code.

The one idea that popped into my mind as I was writing this is that maybe it is possible to mvc-ize a bit the code. If every interaction of the page has to rely on objects, then we can test those objects. This seems to have some limitation in that separating database interactions may be difficult, impossible, or create greater problems that it attempts to solve. But at least it, if used properly, allow for testing of potentially breakable parts of the code.

I will experiment with this idea and see what happens.

Answer from stackoverflow

It's a lot easier if you can upgrade to standard/pro and install ReSharper - it's got a really nice integrated test runner. However, if you can't do that...

* Launch the NUnit GUI
* Load the relevant tests, from debug builds
* In Visual Studio, attach to the NUnit GUI process
* Set your breakpoints
* Launch the relevant test

It's a bit of a pain, but when you've got the shortcut keys memorised (Alt-P is attach to process, IIRC - but check) it's not too bad