Using TDD, how I found that NUnit TestFixtureSetUp and TestFixtureTearDown (from base classes) are not called when a Constructor exists (in the main class)

Just hit an interesting issue which I'm sure there is a good explanation for, but It caught me off guard.

I was working on this NUnit test called Test_Tbot_User_View

How fast do the 'NUnit-Cassini-driven' tests execute (on a full TM instance)

A question I received after posting The moment I was able to serialize objects across an ASP.NET AppDomain and an NUnit AppDomain was 'Ok, that is is interesting, but how fast is it?'

That is actually one of the 'THE' key questions, since if we want to be able to create NUnit tests that use newly created Cassini-driven websites (i.e. a new Cassini server per test or test class) they have to be fast.

Ok, so how 'fast' is fast?

Well, in my book, that is either less than 1 second (for quick tests) or 10 seconds (for more complex setups).

More than that, and it is not practical to run those tests from NCrunch (or even manually via Resharper/NUnit-GUIs)

The good news is that (as you can see below), I was able to execute an 'NUnit-Cassini-driven' test in:

• 6 sec: via NCrunch (consuming a TM instance with 0 libraries)
• 7 sec: via ReSharper (consuming a TM instance with 3 libraries)

The moment I was able to serialize objects across an ASP.NET AppDomain and an NUnit AppDomain

As you can see at the end of How to debug an Cassini hosted website and the UnitTest that uses WatiN to automate that hosted website, although I was now able to start cassini in the current NUnit process, I was still not able to have direct/native access to the running objects of that website.

Basically what I wanted was to be able to access programatically the live TeamMentor (TM) objects from an NUnit test (note that both are running on separate AppDomains).

Not only this would make some of the tests I want to write possible, it would allow me to much faster setup specific test environments (for example cases when I need a number of users to already exist in TM).

The key problem is that after starting the 'TM website running inside Cassini, triggered from the NUnit test' I was left with two AppDomains:

• The NUnit AppDomain running the NUnit Test and the Cassini Server
• The Cassini AppDomain running the TM website

In practice what I wanted to do is to be able to access and edit one of TM objects (for example TeamMentor.Schemas.TM_Config from the NUnit test).

And that is exactly what I was able to do :)

Using WatiN and Embedded Cassini to run complex TeamMentor Automation (Create and Delete an Library)

Here is an QA Automation script I created today which performs a number of Integration Tests on the new version of TeamMentor.

These are the main moving parts (of the QA Environment and script):

• Using an embedded WatiN IE window inside an WinForms window to drive Cassini hosting an .NET 4.5 website (this 'popupWindow' was actually opened from a UnitTest :) )
• Driving the IE browser using  a number of FluentSharp ExtensionMethods
• Number of waits for links to exist (needed due to the Ajax nature of TeamMentor)
• When needed, directly query javascript variables ('window.TM.WebServices.Data.AllLibraries.length') and invoke core TM Javascript APIs ('window.TM.Gui.LibraryTree.remove_Library_from_Database')  
• Use of Lambda methods to create an basic TM API (login, logout, open xyz page, trigger complex workflows, etc...)

Here is what this test QA environment looks like:

E2E testing AngularJS links and routes using NCrunch, VisualStudio and FluentSharp.WatiN

In order to have real TDD while developing AngularJS inside VisualStudio, I needed a way to write C# Unit Tests that could be executed in the background by NCrunch (i.e. in real-time during coding).

Since I wanted to do E2E (End-to-End) testing of the AngularJS app, I needed either a good mocking environment (like the one provided by KarmaJS/AngularJS Mocks) or the real thing (i.e. actually running the app on a local IIS/Cassini server).

If I have the choice, I always prefer to run my tests without mocking (or with as least amount of Mocks as possible), since that allows for a much more realistic test environment, and promotes much better engineering and coding practices.

This post shows how I created such environment and provides a couple examples of C# tests written to check if links created by AngularJS directives and routes are being correctively set.

Problem with AngularJS ng-view, it doesn’t work when inside a directive

I hit an interesting problem yesterday with AngularJS views. They (the views) where working when clicking on a link, but not working when accessed directly, or when the back button was used (which broke the idea of AngularJS routing, since it is supposed to handle those to key scenarios).

After quite a bit of debugging, I was able to track the problem to the fact that if I placed the ng-view directive inside another directive, the refresh and back button would break (although it would work ok for links and direct browser url manipulation).

What is really nice, is that I was able to use the .NET C# based Unit Test infrastructure to confirm this problem and test for it :)

Interesting validation problem on new user's email, caused by a TLD in caps (and using NCrunch to test it)

While working on this issue and improving the Unit Test coverage of TeamMentor's user creation code, I noticed that:

a) these emails worked:


abc@def.ghi , ABC@def.ghi , abc@EDF.ghi

b) but these ones didn't:


abc@def.Ghi , abc@def.gHi , abc@def.GHI

Trying out NCrunch

Intrigued by Kofi’s NCrunch and TeamMentor post, and since today I had to write a number of Unit Tests, I decided to give NCrunch a test drive.

I downloaded the MSI, the install was smooth and next time I opened up VisualStudio there was a new NCrunch menu available: