2010-08-13
Using BDD with SpecFlow, WPF and White
It’s been a while since I blogged. Twitter is taking over. I compensate that with a major blog post.
Background
I written about the project I’m in right now a couple of times before and to make a long story short; we don’t have any requirements! We only have the existing application which we are to “convert” from VB6 to VB.NET. 1:1 is the mantra – which is to be understood as: functional the same.
I have suggested for the team that we work with BDD (or ATDD if you like) to create the requirements as we go. They liked it. A lot!
To not let this post grow totally out of control, I leave the description for that process to another post.
To put my money where my mouth is and show them how it should be accomplished. This blog post is that description.
Solution and tools
SpecFlow
The best BDD-tool I’ve seen for the .NET platform is SpecFlow. It’s a very active open source project that gets more and more attention in the community.
WPF and Prism
We’re going to build a fat client (remember them?) and have decided on building it with WPF and Prism 2 (or 4 was it?) .
Let me right now say that I don’t, yet, know much about Prism and my example in this post is NOT an tutorial on how to build great Prism-applications.
White
The missing part in the solution puzzle was given by the White project. From their website we learn:
White is a framework for automating rich client applications based on Win32, WinForms, WPF, Silverlight and SWT (Java) platforms.
Well – perfect fit, if you ask me. Also – the creators of Prism has used White to acceptance test their own stuff.
Where I learned
I’ve followed the SpecFlow-project for a while now and they have increasingly supplied us with great examples and tutorials. I recommend you check them out. I haven’t seen to much that isn’t web application though.
Likewise the Prism project comes with lot of examples. See their download and learning pages. This description of a Hello World example helped me get started.
White also have some useful examples on their Codeplex-site. I also found this post by Ben Hall useful.
How I did it
Let’s, finally, get down to business. I’ll take this step by step but not supply every detail, for the sake of brevity. The complete code sample can be found here.
The example is very simple calculator. Yes, I know that the example not is a fully fledge application but it proves my point.
Through the example I will use the standards of my current project, which mean VB.NET.
First I downloaded everything I needed:
I then compiled Prism according to the ReadMe.txt and the “Desktop only - Open Composite Application Library.bat”-file, which put the files in \CAL\Desktop\Composite.UnityExtensions\bin\Debug-folder which puzzled me for a while.
Could not help myself to smile when 431 tests passed. Gotta love TDD!
I now created a empty solution for my application, Marcusoft.BDD.Calculator and in doing so got a root-folder for my application.
In this root project folder I created a lib-folder and copied all the Prism binaries (from CAL\Desktop\Composite.UnityExtensions\bin\Debug)
I then moved all the White binaries to the lib-folder as well. My god – it was many – I will not use all of those…
In my solution I created a lib solution folder and pulled all my binaries into Visual Studio. That’s probably not need but I like to see everything I’m using in the solution.
Writing specs
I now turned to the SpecFlow part of things. As this project will serve as a demonstration for my project I wanted to follow my current customers requirements (VB.NET, MSTest etc).
I therefore created a Test-project called Marcusoft.BDD.Calculator.Specs. DON’T try to create a Class library and convert it into a MSTest-project. You will only fail…
In the project I created a folder called Steps and removed the ubiquitous UnitTest1.vb-file. I also added a reference to TechTalk.SpecFlow.dll from my lib-folder.
One cool feature with SpecFlow is that you can put some rules for how your features are to be written in configuration. That’s stuff like test runner and other technical configuration but also the language used for you features and scenarios. This will give you compilation errors for typos in your requirements! I actually scream of joy when that happened.
So I added an App.config with the following content:
I used sv-SE to enable Swedish for my language setting. But I switched to en-US to get English for this post.
Now I created a .feature-file to get my first SpecFlow-feature. The feature is called: SumTwoPositiveInteger and looks like this:
Please not that I pay homage to the SpecFlow-template :)
Also, on a more serious note, this is a very imperative (vs. declarative) style of writing scenarios. That fit’s our needs very well but maybe not yours…
As the BDD cycle says I could now compile and run my tests to get a Inconclusive result and some help on how to continue. The code I was suggested is in C# but that’s easily translated with this tool. Not to bothered with that. Yet.
So the first version of my steps matched this precisely. That could work for now. I could now start my outside-in development cycle and write some code.
When I now ran my tests they are all pending. Which gives me an opportunity to write some production code.
Writing application code
Here I followed the description in the HelloWorld-post I mentioned before, to get my skeleton code up and running. I will not repeat it here. I called my Shell Marcusoft.BDD.Calculator.Desktop and the module Marcusoft.BDD.Calculator.Module.
On trick was the Application.xaml is called Application and not App. This result in trouble since we’re inheriting from a Prism-class called Application. When you change the name there are 3 places to do it in… or use refactoring…
When you have created your module and got it to run and display an empty form, you’re ready to continue on.
Automating with White
Starting the application
The first thing I started out with was my background:
Background:
Given that the application is started
To achieve this I had to find a way to start the application via White.
So first I referenced White.Core.dll and put a reference from Marcusoft.BDD.Calculator.Specs to the system under test (Marcusoft.BDD.Calculator.Desktop)
I then used the BeforeFeature-attribute of SpecFlow to start the application (or attach me to it) and the AfterFeature to kill it. That made me write this code:
Writing in textboxes
Now we’re cooking. This actually starts my application and displays the form. On to the next order of business…
The first row in my scenario says:
Given that I write 2 in the textbox Number 1
I need some way to get hold of a textbox and write the specified number in it.
First I cleaned up my step to match all those occurrences. Here is the Given-attribute and method declaration for that:
This will send the number after “that i write” as stringUserEntered and the name of the box after “textbox” as wellKnownNameOfTextbox.
With that in place I could remove the other two givens that was exact matches for specific number.
A problem occurred with the name of the textbox. When writing the specifications we don’t want to write the ID of the textbox (txtNumber1 for example). Instead we want some kind of well known name that the users refers to the box with. Often that will be the name of the label for the control.
In this simplified example I have implemented a convention (over configuration). All textboxes have the same name (in lowercase and without spaces) as their label. That may not hold for ever but works for now.
I could now write a method that returns a control, of a given type, based on the well-known name for that control. Here it is:
I ran my tests again to watch them fail since there was no control on the form called “number1”. Great – no I can write production code.
I updated the user control with a label and textbox called Number 1, and then ran my tests again and … progress! The correct number was filled in.
And the regular expression matches for both textboxes – so I when I get the next error (no textbox for named number2), i can safely add some production code and controls for that.
I had now worked my way outside, from the scenario / requirements, in to the actual implementation.
Love this!
Selecting in Combo-boxes
The final pieces comes together quite easy. I updated the Given-statement that SpecFlow-generated for Calculation Type from this:
<Given("that I choose '\+' in the list Type")>
to this:
<Given("that I choose '(.*)' in the list (.*)")>
And then implemented a generic method that selects a value from a combo box like follows:
That drove me to put the a Combo-box on the view. And got another part of my feature passing.
We’re getting there. One step at the time.
Clicking buttons
To click a button it’s as simple as:
And the following method to check the content of a textbox:
With these two methods I could bring the whole feature together. And it fails and tells me that 5 is expected but it got an empty string. I can now implement the functionality for the feature.
Conclusion
This blog post is getting ridiculously long already so I better wrap it.
From now on I continued on driving my implementation from the scenarios. I took very small steps as described above, so I always knew where I was.
It took quite some time before I could get my first feature flying, but by then I had a real nice set of step’s that could be reused by the next feature. Which led to that the subsequent features were really fast to implement. I added scenarios for subtraction, division and multiplication. Which didn’t force me to write anything but production code!
What didn’t I do
I haven’t included anything on TDD in this post. And I didn’t do any. That doesn’t mean that I don’t think it’s needed, but I didn’t wanted to mix any of that into this example.
I will sure have to work more on the handling of names and references to them. There is an article on that in the White functional testing documentation, that talks about screen objects. Also I recommend watching this video on how to test the GUI in a web application. It gave me some valuable insights on how ATDD might influence your code and naming etc.
The code
The code be downloaded here. I will sure work on it – so it might update from time to time.
Final thoughts
This has been a very technical post with lots of code. But remember – it’s not in the tool!
For me the biggest take away when working like this is the way you can collaborate with customer, analysist and tester when writing your features and scenarios.
That’s so much more important than any tool.
If you read all of this – thank you. You have been an awesome audience ;)
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Tools
.NET
Agile
2010-06-14
Resovling policy enabled objects with Unity 2.0
I had the opportunity to use Unity and Enterprise Libarary in my current project. On of the really cool features of Enterprise Library (and most Dependency Injection frameworks) is the support for Aspect Oriented Programming. It’s a really neat way of handling the cross-cutting concerns in your application.
I was therefore very surprised when I had a really hard time to get, what I thought was simple, the following scenario to work:
I want the objects that I resolve to be “policy enabled” – i.e. configured in such a way that I can add policies in the configuration that can be picked up later and applied to the resolved objects.
That is, it was hard in Enterprise Library 4.1 and Unity 1.2. I had to scan the net and put together a solution of my own. It was a mix of extension methods, wrappers and some low-level enterprise library tweaking. You know, the kind of code that doesn’t make you feel proud after you wrote it.
And then Unity 2.0 and Enterprise Library was released. All my problems gone! Everything is simple and the sun is always shining. … Not quite – the scenario I was looking for was a bit tricky still. But the solution a lot cleaner.
I asked a question about in on both StackOverflow and in the Unity Community and soon got an answer. In the unity thread I’ve posted a complete code example of the solution.
In short the answer was to add an extension called EnterpriseLibraryCoreExtension, like this:
_container.AddNewExtension<EnterpriseLibraryCoreExtension>();
Using this extension will instruct Unity to pick up my configuration with, in this example, the policies and apply them to the resolved object.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Tools
.NET
2010-05-11
WCF, MVVM and good client design
Up to now most of my assignments has not been client-related. Often the project description and main focus is on the layers beneath the GUI. But lately I have seen a shift in the industry and more so in my own interest. Client-side stuff is coming on strong.
And it’s hard work to design a well structured client application. There are a lot of patterns but the frameworks and “recommended” ways up to now often doesn’t lend themselves well to those patterns. Ever tried to do proper MVC with WebForms or WinForms – it’s not easy.
But that has also shifted. I have written a lot on ASP.NET MVC – that of course supports the mother of all client patterns, MVC, in a great way. So enough said there.
But for “fat clients” such as windows clients there’s been a hazy mystery for me. I know OF WPF but I don’t know WPF. And they seems to talk a lot about the MVVM (Model-View-ViewModel) pattern.
To the extent of my knowledge now the MVVM pattern is an adaptation of Martin Fowlers Presentation Model pattern. An adaptation that make full use of the WPF DataBinding capabilities.
I’ve found some great resources on this – starting with this excellent presentation on the pattern, by Jason Dolinger. Here is his source code
After that I thought that there must be frameworks that helps me with this. And there are. About as many as there are WPF developers… Here is a great StackOverflow post that helps you choose one.
And following one of those links (to the MVVM Foundation) I finally found and read this great MSDN Magazine article by Josh Smith.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
.NET
Life of a consultant
2010-05-06
Configure WCF in IIS for anonymous access
This case may sound strange and I have seen loads of post that describes how to get out of this behavior. But we have a case where we want to allow anonymous access and the let a external component manage the security validation.
This turned out to be very hard to figure out and required some wizard-like skills of Anders Granåker amongst others.
OK – the case is very simple. I have a WCF Service that I want to allow anonymous access to. I don’t care about message and transport security (for now). Just allow anonymous access – I’ll take care of the authorization in code.
Here is what I had to do to get it to work on Windows 2003 R2:
- Create a account on the server
- Put that account into the IIS_WPG group
- Create a virtual directory for my WCF service
- Create an application in that virtual directory
- Set the account as Identity on the application pool that the virtual directory is using (DefaultAppPool for example)
- Set the account as the anonymous account the virtual directory is running under (Directory Security)
- IISReset to get the settings to take
The last step is a bit interesting… In this time and age you could think that a simple recycling of the application pool would be enough but … no. Do an IISReset to be sure.
Another gotcha that confused us a lot was that when you set an account to be the anonymous account for the virtual directory, you’re prompted to set the password. And retype it to be sure. But that password is not check if it’s the right password! Beware – I locked out our administrator account due to this.
Now it works – and we have a build script that is doing regressions tests via SOAPUI.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
WCF
Life of a consultant
MSBuild
2010-04-22
Specification by example – the missing link?
I’ve been thinking. That statement alone will be sure to put fear in the heart of a lot of you… But if you have continued on this far, here we go.
Learning programming stuff
During the last year or so I have been reading a lot. I have read stuff on XP, on good design DDD and TDD. This reading has affected me and my coding style way much more than I first thought. I simply cannot write code anymore without the test first, interface first, thinking of SOLID etc..
Learning lean stuff
At the same time I have change role at Avega. I am now an AvegaCoach. This means that my time is divided between my regular (often coaching) assignments with customers and Avega and Elevate. Since my fellow AvegaCoaches (Joakim and Christophe) and me are interested in agile and lean stuff we have focused our joint efforts on that.
This has led that I have learned a lot from them about lean and Kanban. And this has expanded my understanding of Scrum and how to work agile.
Frustrations
But around here the frustration started to kick in. I felt that these two areas; technology and process stuff could marry in a great way. But how? And how much does the it affect each other?
Also, a specific thing that I have been really frustrated in is how to include test in an agile world. Testing are left out in planning, are left to try to keep up with development and the regression stuff will eventually kill them. So “testing sprints” are introduced, “we’re running a sprint behind the rest of the team” and other solutions like that is used to try to get around it.
Surely – this cannot be the best case? So I started read about agile testing. I loved the book by Gjoko Adzic. This book introduced me to the term agile acceptance testing and specification by example.
The solution?
I have heard and learned quite a lot about BDD. I knew that BDD and “outside-in” thinking can help me design my application in a maintainable way. But BDD can be applied at any level. It could be used to spec out your unit test. Another way to do TDD (AAA becomes GWT)
But I had missed the fact that the specifications and features should could be written in collaboration with customer or business analysists. This will turn the specs into executable specifications. (Those words still gives me the shivers. It’s so cool!)
That’s the thing! With executable specifications you have a living specification to code against, and the moment you’re done (as in done done) with the story the specification is “magically” turned into an acceptance test.
And the specifications finally reflects what the code is doing. I can never forget a quote by a customer how very proudly showed me the folder with all the specifications (use cases in this case) and then told me:
“And the best thing… they are almost up to date with what the system does”.
The really scary part about that is that it was actually the best I ever seen. Most documentation and specifications are a violation to the DRY principle. But with executable specifications you’re as close as it gets.
But it doesn’t stop there: since the specification with any current tool is written in plain English you can workshop around it to get everybody's (business analysis, testing, coding, deploy etc) views on the matter. And you minimize the misconceptions by using real world examples.
And that in turn closes the gap for me; agile testing is hard since I am still viewing testing as something separate from coding. And the same goes for specifying… But it’s not! You can do this in agile way, a little slice of functionality at the time. A way to do that is specification by example.
Recommended watching and reading
Read Gojkos book – Bridging the communication gap. Stop reading whatever you reading now and start reading this. It was a eye-opener for me.
Watch (anything you can get your hands on) this webcast by Dan North. There are lots of great stuff in here on BDD and design.
I’m reading Agile Testing right now. That has really showed me that testing is something that any agile person (developer, tester, business analysist etc.) should care about. Or as Deming put it:
“Quality is everyone's responsibility.”
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Scrum
Agile
Life of a consultant
DDD
2010-03-30
Changing endpoint from the command line when testing services with SOAPUi
I have been singing SOAPUi’s praises lately and it’s really great for testing services. In this post I describe how I made the whole thing work for testing WCF Services.
But, as stated in this post, there was still one more thing to be solved… The endpoints from the command line. You want to use different endpoints in different environments. And in my specific customer case I want one of them to stay the same all of the time, since that endpoint points (sorry, could not resist myself) to a “singleton” kind of service.
Luckily the SOAPUi team also have some great support (Thanks Ole, who replied in Swedish!). So here you have it – how to change the endpoint for one of your services under test from the command line – which in my case means the build script.
- I first created a sample WCF service project (very vanilla, i didn’t touch the code just the default generated code).
By the way; really cool hosting and test client stuff in Visual Studio 2010 - I changed the binding to basicHttpBinding since that’s the only thing that work with SOAPUi. I used the WCF Service Configuration tool in Visual Studio of course.
- I then created a normal SOAPUi project and let SOAPUi create testcases for me. I added asserts just to make sure that the I didn’t get an error back.
- I started my service and ran the testcases – It worked!
- I then, and here is the trick, created a project-wide property (Click project file and chose Custom properties in the lower part of the project window) to hold the endpoint value.
- I named the project wide property DemoServiceEndpoint
- I gave it the address of the service I was testing as value
- I then opened the tree down to the test request in question and then chose the Test Property-tab in the lower part of the project tree
- Here I entered this expression that reads the value from my project wide property:
${#Project#DemoServiceEndpoint} - I repeated for my other test request and tested. It still worked!
- OK – we’re closing in now. Now I used the Test Runner to create my command (nifty stuff SOAPUi dudes!). Here I got the opportunity to set my parameter ${#Project#DemoServiceEndpoint}.
- After some tweaking I managed to “harvest” the command into a .bat-file.
"C:\Program Files (x86)\eviware\soapUI-3.5\bin\testrunner.bat" -sDemoTestSuite -PDemoServiceEndpoint=http://localhost:8732/Design_Time_Addresses/Marcusoft.SOAPUiDemo.WCFService/Service1/ C:\Dev\Marcusoft.SOAPUiDemo\EndPointOverrideDemo-soapui-project.xml
- And it worked!
So now I can change the endpoint from the command line! In my build script when I have deployed the service to the testing environment for example! Yeah!
You can download my example here.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Tools
.NET
WCF
Life of a consultant
MSBuild
2010-03-30
Status of work items – where to keep it
This is a question that arises very soon or sometime even before you start doing work with a board; Scrum, Kanban or Scrumbut.
Where should the status be? Or more often – “let’s use TFS” (and keep the work items in TFS/SharePoint/Excel and then make copies of them to use on the wall).
A variant of the question is; “we are a distributed team – can we still use the same board?”
Well of course there is not a yes or no answer to that but here is my take on it:
Low tech rules!
First I think that no electronic system will ever beat the flexibility, simplicity and agileness of a board. See this for some examples. There are some that have come close but a low tech board communicates so much information with the added flexibility to move things around very easy.
Also using a board promotes face-to-face communication which is always good. I have been in teams where the status of the electronic system should be updated before the daily standup – what use is the meeting then?
Master data problem
Secondly this problem is a master-data problem; who is the master of the status?
There are places, big companies, distributed team etc. where electronic systems are the only way (or so they say ;)). Then you’ll have to use them. But be sure to know where your master status is – on the board or in the system?
When I did my military service I learned: “if the map and reality mismatch then the map is correct” (or master). That shows how master data problems is handled in a bad way, I think. Know where your master status is and treat all other sources as non-masters or copies.
Use the tool not the other way around
Finally – it’s not in the tool. Or put differently these are just tools. Tools are meant to be used by people to get task done easier. Not to add load to the burden.
If you ever find yourself complaining (as I have… a lot…) of having to update TFS with the status of the board – then the tool is using you. Not a very clever way to use your time. Waste – in Lean terms.
How I would do it
If I ever got the chance to decide on stuff like this (Hey, I sometimes do!) I would do it like this:
- Keep your work items and their status on the physical board
- Let the physical board be the master of status for the work items
- Use the electronic system to keep reference data that doesn’t need to be on the physical board.
- Do not keep status of the work item in the electronic system, or rather not all of them. You could keep a simplified status chain (Not started/Started/Done for example)
- Put a reference on the work item on the board to the ID inside the electronic system
- “Stamp” work items with the dates they enter a new stage of your workflow. You can then use these data to find bottlenecks in your workflow, make predictions (search for Disneyland) and get some really nice follow-up-data
- Keep in synch within distributed teams by using any means possible; web cams, digital photos, telephone, IPhone video calls, travel; are some of the ways I have tried to solve this.
- Use the board to get your work to flow smoother – don’t add more work to keep the board and any system up-to-date.
That’s a few thoughts on the subject.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Scrum
Agile
2010-03-28
Practical Kanban – some Kanban boards in practices
Together with Joakim Sundén and Christophe Achouiantz I’ve been doing some talks on Kanban. We have included some practicality in the talk – Build your own Kanban-board sort of.
For the first few talks I tried to draw as fast as Joakim (in that case) talked. Not an easy task – try it. And also my drawings were not always optimal.
So Joakim and I did some stop-motion-action and created slides for this part instead. It took the better part of a complete day… But the result was alright I think.
Here are the slides with some short comments to illustrate what we talk about.
Postad av Marcus Hammarberg
Kommentarer (0)
Kategorier:
Agile