thoughts on coding

April 23, 2012

Testing WWA apps with Jasmine on Windows 8

Filed under: TDD, WWA — Tags: , , , , , , — Frantisek @ 9:51 pm

I work on a project which is WWA app and I must admit that:

  •  the code can quickly ends up in the mess,
  • the language itself is dynamic so there are no compile time errors (just runtime errors)

One of the ways how to ensure higher code quality is unit testing.

I paste here 2 vey important notes about unit testing from this blog because many people argue that they don’t have time to write unit tests OR it’s to advanced approach for them.

Testing is an advanced practice for the pros, not for me

My position is that whatever way you think of your process for writing code, you are testing it, e.g. by refreshing your browser(s) to verify that it is doing what it should. You are simply opting out of automating and improving your testing process, and in the long run (or even not-so-long run) you are spending more time hammering your browser’s refresh button than I spend writing tests that I can run today, tomorrow and next year should I so please.

Testing takes too much time, I’d rather just write production code

Both manual and automated testing takes time. But please, don’t spend an hour or two “evaluating” unit testing and/or TDD and then decide it is a waste of time. Unit testing and TDD are disciplines that need to be practiced just like any other. There is no way to get good at automated testing in a few hours. You need practice, and once you get there, then you will recognize the benefits I’m describing here, and then you will realize how much of a waste manual ad-hoc testing is. Besides, even if writing unit tests and testing your code rigorously takes a little more time, what would you prefer? To fail really fast, or to succeed?

Current situation

Unfortunatelly, there is no project template for unit testings of WWA apps in Visual Studio 2011. There are different projects templates for authoring WWA apps with VS 2011 but NO project template for unit testing and it’s a shame. We, inside Microsoft have the ways how to test WWA apps but they are not public.

The best would be to have a publicly available way how to test WWA apps with community behind.


First of all, there are some unit testing plugins into VS IDE like JustCode from Telerik or Unit testing plugin from JetBrains but no for running them as Metro WWA application.  So I had to invent my own solution. I had to port Jasmine runner including my own extensions in order to run the unit tests for WWA apps on Windows 8.

I use Jasmine as unit testing framework. I wrote a shell page (or so called test runner shell) which is set as the start page. The shell page runs the whole process which consist of:

  1. configuring Jasmine,
  2. discovering tests and
  3. running the tests upon user input.

In order to fit with Jasmine I had to write also a Jasmine reporter which communicates with the shell and reports the progress of tests execution.

Enought theory, example please.

I ported a referral example from Jasmine project and here is the result:

You can download the code from It’s in the folder misc\SampleTests

How all this works:

There are two main things:

  1. all test files ends with *tests.js. It’s configurable via jasmine.wwa.fileFilter. Example: jasmine.wwa.testFilesFilter = “*spec.js”;
  2.  unit testing project is configured to start test runner shell file: shell.html.

The shell loads and run ALL test files. A test file itself registers test suite and specs into the jasmine environment. Please note that shell runner follows M-V-VM style.

Future development

The shell runner will be updated quite much as MvvmJS is going to be extended with different aspects, e.g. binding extenions, controls, etc.

If you want to use it on your project, just copy the whole project and add your tests – the shell will discover your tests and you will be able to run them.

Happy testing on WWA!

March 25, 2010

NBehave out, StoryQ in

Filed under: BDD, NBehave, StoryQ, TDD, Uncategorized — Tags: , — Frantisek @ 10:39 am

I use Behavior Driven Development (BDD) style of the development for last few years. Just for the explanation as I see BDD, BDD is Test-Driven development (TDD) with the description of the tests.

I used TDD in past but I found out that I wrote many comments in the code. Then I started to extract the commented code into the methods whose name was exactly that comment. BDD enables to translate the method names into the text and export that text while running the test. You can find very nice example of this here or exactly the steps I described here. Please note fluent style of the naming the methods and basically all the stuff.

By the way, you can read about the core BDD syntax here.

Until now we used NBehave to define the stories but … I think the biggest disadvantage of this library is the string-adidtive style.

    1          WithScenario("text ......")

    2                 .Given("a text describing give ", "arg", arg => {/* some code*/ })

    3                 .When("a text describing when operation", () => {/* some code*/ })

    4                 .Then("a text describing then operation with expectation", "expectation",  arg => {/* some code*/ })

In case of having 2 tests which share the same test step, i.e. …… it’s recommended (in order to follow DRY principle) to extract the code to the method and use this method in the test.


    1             WithScenario("text ......")

    2                    .Given("a text describing give ", "arg", TextDescribingGiven)

    3                    .When("a text describing when operation", () => {/* some code*/ })

    4                    .Then("a text describing then operation with expectation", "expectation", arg => {/* some code*/ });


    6             WithScenario("text 2......")

    7                    .Given("a text describing give ", "arg", TextDescribingGiven)

    8                    .When("a text describing when operation", () => {/* some code*/ })

    9                    .Then("a text describing then operation with expectation", "expectation", arg => {/* some code*/ });



   12         private void TextDescribingGiven(string arg)

   13         {

   14             /* some code*/

   15         }

It was usual that we changed the code in the step, so we changed the method name, too (using refactoring). But we were too lazy to change also the strings which described the step name. This resulted into wrongly named step decriptions => test description is useless. The developers have to follow very strict rules and you know how hard it is. This functionality was used in NBehave v0.3 and v0.4.

NBehave team released new version 0.4.5 which makes all the above mentioned usage obsolete and dictates us to write the stories in the external file in text form! and then map it (via strings!!!) against the  code! It’s strange step for me because many .NET community stuff tries to avoid using string (i.e. Expressions, etc.) This is hardcore step, I would say. I hate strings and it’s to avoid them as much as possible.  That was the reason why I tried to find out some another library which could create the step description from the method name (methods were named fluently) or we will try to write our own.

We used NBehave for 3 years and we tried to integrate them into NUnit tests with using Resharper to run the tests but …


StoryQ is another BDD library you can use to write the BDD tests but it has the following cooooooool features:

  1. step description is created from the method name, i.e. .Given(IHaveTypedMyCreditCardNumberIntoTheCheckoutPage) => translates to => Given I have typed my credit card number into the checkout page
  2. Nice posibility to add ParameterFormatAttributes
  3. Nice/painless integration into pure NUnit/MSTests testing => integrated into Resharper/VS.NET IDE
  4. Sexy exports into the reports (using XML, XSLT) nicely integrated with continous integration i.e. TFS build server
  5. amazing StoryQ Converter GUI which enables you to write the stories and translate them into the code – it creates testing code envelope!

Check all these features on their web. There is qood documentation.

My comments and enhancements to StoryQ
After using StoryQ for some time I found out that it would good (at least fro my point of the view) the following extensions/changes (we did few of them):

  1. we used to write 1 story in 1 class but with several scenarios. Each scenario is the separated test method. Because there are several strings (again used), I would suggest:
    • scenario description should be created based on the method name
    • story name could be created based on the whole class name

    This extentions/change could avoid using strings. The question is how this could be integrated into NUnit without any pain in order to get the textual representation of the tests.

  2. calling the method  .ExecuteWithSimpleReport(MethodBase.GetCurrentMethod()); we changed to .Run(); using the following extentions method:
  3.    11 public static void Run(this Outcome outcome)

       12         {

       13             StackTrace st = new StackTrace();

       14             outcome.ExecuteWithReport(st.GetFrame(1).GetMethod());

       15         }

  4. Empty String-typed arguments are displayed as ” – nothing – so I created EmptyStringParameterFormatAttribute:
  5.     5 public class EmptyStringParameterFormatAttribute : ParameterFormatAttribute     6     {     7         public override string Format(object value)     8         {     9             if (value != null)    10             {    11                 var str = value as string;    12                 if (str == null || str.Length != 0)    13                 {    14                     return value.ToString();    15                 }    16                 return "empty string";    17             }    18             return "{NULL}";    19     20         }    21     }
  6. It’s big shame that StoryQ Converter doesn’t use T4 templates to generate the code because it would be good to extend/change the default code generation which is currently hard-coded.
  7. It would be good if it would be possible to specify in StoryQ Converter also the argument names, i.e.  when building the shared component with $id:1 => could create a code (BuildingTheSharedComponentWithId, 1) and the method signature could be BuildingTheSharedComponentWithId(int id). It’s just a nice to have feature 😮

I must say StoryQ is really coool library with amazing Converter. Btw, it was really nice to read and know how SrotyQ team developed this library – usign Flit (Fluent Interface toolkit in conjuction with Irony and Dot/GraphViz) which is really coool way and it’s worth another blog posts.

That’s all for now …

Create a free website or blog at