FluentSharp July 2014 Update - Better README.MD page, list of issues to help and NuGet Packages

I just cleaned up the main FluentSharp README.md file (with lots of info) and added a number of issues to:

• https://github.com/o2platform/FluentSharp/issues
• https://github.com/o2platform/FluentSharp_Fork.WatiN/issues
• https://github.com/o2platform/O2.Platform.Scripts/issues

Please take a look and see which ones you would like to solve :)

As you can see by the commit activity (graphs/contributors and commits/master) there has been quite a number of API updates and fixes (for example there is quite a lot of great new stuff on the WatiN IE Web Automation front, including native support for Cassini).

Although I have not created a separate O2 Platform exe release, you can already get all the APIs from the NuGet packages:

• FluentSharp.CoreLib
• FluentSharp.REPL
• FluentSharp.NUnit
• FluentSharp.WatiN
• FluentSharp.WatiN.NUnit
• FluentSharp.CassiniDev.NUnit
• FluentSharp.NGit
• FluentSharp.WinForms
• FluentSharp.Moq

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

From NUnit AppDomain, accessing properties and invoking methods on 'Serializable MarshalByRefObject TeamMentor objects' (hosted on Cassini's AppDomain)

After How fast do the 'NUnit-Cassini-driven' tests execute (on a full TM instance) it was time to start accessing internal TeamMentor objects from the NUnit AppDomain.

The main change I did was to add the [Serializable] and the MarshalByRefObject to the TeamMentor (TM) objects that I want to consume (i.e. access data and invoke methods) from NUnit tests.

Here is an example of what it looks like in one of the main TM's data classes:

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

How to debug an Cassini hosted website and the UnitTest that uses WatiN to automate that hosted website

One of the cool new capabilities that I'm using when writing QA Automation scripts for the latest version of TeamMentor, is the https://www.nuget.org/packages/FluentSharp.CassiniDev which allows the execution of an an 'in memory' version of Cassini (hosting the full TeamMentor website) in the same process as the Unit Test driving the IE automation of the hosted website (using FluentSharp.WatiN)

In practice, what this means is that the UnitTests are being executed in the same process as the main TeamMentor Website. This something that I have been wanting to have for ages, and the key capability I gained from it was the ability to debug both live website and UnitTest in the same session.

Lets set it in action.

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: