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 …

November 28, 2007

Story about stories or “how we started to do BDD”

Filed under: Uncategorized — Tags: — Frantisek @ 9:55 pm

My colleagues started to work on the project where the team was split into 2 subteams located on different places. The problem was that our part (development) was dependent on the second part (DBAs, business). The project started and we found there is a problem with the cooperation – specification was unclear, DBAs did a stored procedures but didnt test the correctnes of them, developers spent quite much time analyzing why the stored procedure doesnt work, they tried to change the stored procedures with informing DBAs what was changed, etc. At the end of the day the process was time-consuming.

BDD is comming.
When the project started to be in red numbers, my boss asked me to find a solution for it as I’m lead developer in our company. I knew that this is right time to come with a new approach – I found BDD. I started with idea that we need to be independet from DBAs and we should be the masters who will instruct them how to write the st.procedures. The project was developed using “developing against interfaces” approach in conjuction with Spring.NET, Dependecy Injection, etc. I came with idea that we create a mock data access layer (DAL) which returns fake data just to do our development. It was also necessary to somehow specify the behaviour of DAL – at the end the stored procedures.  Did you see the word “behaviour”?  So I  started to do TDD. As I had a practice with it, I wanted something which describes the dehavior of the system and the description of the test will not stay in the code only. Fortunatelly, I found NBehave.  

I must say as the developers are lazy, it’s very hard to ask them to start to think in new way. First write the test, then the code and then do refactoring. Even now, after 2 months of BDD some skilled member of the team has problems with it. Anyway I did a sample on audit message logging part of the system. I showed it to the developers and we started. After few weeks we started to ask DBAs to create the procedures which have the behaviour described in the specification which are coded and tested. When DBAs create the procedure, we employ it into the DAL,  change the setting of Spring.NET factory and test it. It works perfectly because we dont loose the time analyzing the procedures, every changes (even system settings) in DB are tested. We use NBehave in conjuction with Spring.NET and Rhino.Mock.

Why to use BDD?  What is the added value?
I must say it’s very big.
1) The developer thinks about the code before coding it. First, it takes a time but at the end of the day, he is sure the code is under tests and wokring fine.
2) Description of the test = behaviour of the code. It’s the most critical part, I think. The test are described using business/natural readable form. Via TDD only the developer knwos what the test is doing. With BDD the business people(BP) or project leader(PL) can check what the test is really testing (or at least should). The PL or BP can checks what is the current situation with the project.
3) When writing BDD specs in the code BDD forces the developers (wo are very lazy) to write the descriptions of the tests in the understandable format. It’s visible to the PL so they needs to be quite responsible to do it.
4)BDD is about description of the application behaviour. The best person to write them are business people. But it’s very hard to ask them to do it. We have our testers/analysts who write the testing scenarions (do you see?) Testers need to understand the system in order to test it well. So I think the best way is to ask testers/analysts to write the stories with testing scenarios for application parts. For some specific parts developers can do it, too. 

BDD for UI?
BDD goes in hand with MVP pattern – model view presenter. It enables us to describe also the behaiour of the screens.

NBehave is great tool to use for BDD and describe the  system. The descrition stays in the code, it’s still up to date and under teh tests, it doesnt stay in word document, it’s still usefull to track the status of the project.

What is missing?
1)I miss the conjuction with CruiseControl.NET very much. This automated build process and intergration is the access point for PLs and business people to check the status of the project and they should see it automatically with each build.
2)I miss support for Exceptions. I mean a code like:

story.WithScenario(“scenario”).Given(“precondition”).ExpectException(“business exception”).When(“do an action”);

In the next my blog entries I’ll write about examples how do we use Spring.NET, Rhino.Mock, NUnit in conjuction with NBehave.


Create a free website or blog at