DotNetNuke Automated GUI Testing

The DotNetNuke Quality Team has been working on Automated GUI Testing for several months now. A project has of course been created on CodePlex. Tools of choice are Gallio, MbUnit and WatiN. We’ve been lucky to get Jeroen van Menen aboard the project, as he is the creator and leader of the WatiN project. You will need to install Gallio and MbUnit before you start. Installing WatiN is also a good idea, but since the binaries are included, that’s not strictly nessecary.

In this post, I’ll be showing how to get started with the DotNetNue Automation Project, ultimately to be able to start writing your own automated tests.

Step 1: get the sources

You need to get the sourcefiles of the CodePlex project. Personally, I prefer to use Tortoise and SVN to connect to CodePlex:

As you can see I’m using a checkout command to get the sources. Since the download is almost 40MB, it might take a few minutes to download.

What we have now, is a folder containing all the sources:

 Step 2: Open the solution

Next, we’ll open up the solution DotNetNuke_WatiN_Tests which resides in the root of the AutomationTests folder. If you don’t have TFS Explorer installed, you’ll get a warning about that because the are TFS bindings in the solution:

Step 3: Set up the environment

In the solution explorer, navigate to the DotNetNuke.Tests.WatiN project and open up the app.config file. Without getting into all the details of the configuration file, there’s a few elements we need to have a look at.

First, there’s the SiteURL settings. Although you can of course change the setting to suit your own needs, I’ll just stick to this one and create a brand new DotNetNuke CE 5.2.2 installation at this URL.

The same goes for the database: while I could create a database with any name, I’ll take the easy way out here and just name it DNN_522_Test. You might want to change the DatabaseServer setting too by the way.

Next we’ll need to make sure the test file location settings are correct. Since I don’t have a D drive, I’ll have to change these settings. You can choose to name your path without drive specification, in which case it will be assumed to be a subfolder of TestRoot, or specify a fully qualified path.

Finally, we need to put the “clean” database files in the folder specified in “DatabasePath”. This is used to assure that the tests are always run on the same DotNetNuke installation, and that it doesn’t get “dirty” from running tests over and over again. De files we need to copy to the folder, are the detached databasefiles. If you navigate to your database in SQL Server Management Studio, right-click it, then Tasks, then Detach to get the Detach Database dialog. Make sure you know where those files are before you detach them. You can find that out on the Database Properties Dialog:

Once you have detached the files, you can copy them to the “DatabasePath” folder and Attach the database files again in SSMS.

Step 4: Test!

I chose to click the Gallio icon next to the class declaration for the LoginTests class to run the tests. After some compiling you will notice that Internet Explorer will run and navigate to your test site. After all tests are completed you can read the test report to see if anything went wrong.

In my case, on of the tests failed but that’s just a minor detail…

Step 5: Write your own test!

Using this setup, you can easily start writing your own test. We encourage you to do so. Let’s hear about all the great tests your wrote and keep running them on each and every beta release of DotNetNuke.