Just been looking at Tilt, a Firefox add-in that shows a 3D visualisation of a webpage. The result is pretty spectacular.
Recent Posts
-
Check out Tilt
-
Mobile site or media queries
At the moment I’m consider the approach we take to mobile web for a major retail site. The most appealing technical solution seems to be making use of CSS3 media queries to munge the layout for different resolutions and serve the same content presented differently.
I’m mulling over whether this is actually practical, or if the content you wish to present to mobile and the overall experience is sufficient different to warrant a seperate UX design and site build.
I think this has to be based on what you’re trying to achieve, and in this case the user needs are not significantly different. The only change is that the way of presenting the experience will differ when dealing with a smaller resolution device.
I’m pretty sure that serving similar content with a more linear presentation would be sufficient to massively increase the usability of the site, and it would definitely seem like a much cheaper option. However, I have to bear in mind that CSS is fun, and working with agencies no so much. I guess I may be a little biased…
-
Resharper 6 shows colour previews when editing CSS
Just noticed a cool feature of Resharper – if you’re editing a colour value in a CSS file, it displays a little bar of the chosen colour underneath. Makes it so much easier to work out what is going on, very nice!
-
Moving away from Delicious
I’m just setting up my home PC afresh and figured I should move away from Delicious given the uncertainty around it’s future.
After a little research I’ve switched to Google Bookmarks along with the GMarks plugin for Firefox and I’m pretty happy.
There’s a feature to import existing bookmarks from Delicious, so I’ve pretty much covered everything I was looking for.
-
Warp tracks now available on Spotify
It looks like a load of Electronica albums are now available on Spotify, wonder if they’ve done a deal with Warp. Been listening to Squarepusher, Planetarium in particular. Also the Tron: Legacy soundtrack from Daft Punk.
-
Principles of BDD, and the impact on unit testing
I’ve been working with BDD for a little while now in delivering a practical project, and have started to get a good sense of what is important. Initially I found that a lot of the articles and reading material made sense but were quite abstract. I agreed with the points made in a general sense, but had some questions around the actual practical application that weren’t necessarily answered.
Everything pulls from the defined scenarios
The main thing I like about the BDD workflow is that it gives you great structure around how to approach a project. Often when you first start something new it can be a little daunting to know where to begin – whether you start designing a schema, writing some unit tests (which tests, where do you start…), if you begin by writing up some user stories and apply an agile structure around it etc.
The great thing with BDD is that you are either writing some new features or scenarios using a plain English language, or you are implementing tests to deliver those scenarios. Every piece of code that you write and every test should be directly ‘pulling’ from the defined scenarios. As soon as you have finished implementing tests to prove a given scenario, you move on to the next. If you run out of scenarios, you either write some more scenarios for the current feature, or you begin defining a new feature. At any point in time, you pretty much know exactly what to do next.
How does BDD affect unit tests?
A big area of confusion that I initially had was how BDD affects unit testing – whether unit tests are effectively replaced by the natural language scenarios, and if you are testing more granular technical detail if you are meant to try to express this from an end user point of view with the scenarios etc.
A user’s experience with software is entirely based on the interactions they have with the user interface. Therefore it makes sense to define the expected behaviours from a user’s point of view, in terms of what the current situation is (Given), what action they take (When) and what the expected result is (Then).
It works quite well to have executable tests for these scenarios to test the user interface, and mock the dependencies. In my project this means testing the MVC controllers and action methods, but mocking the application services. Using a mocking framework you set up the expected behaviour from the dependencies in the ‘Given’ steps, the ‘When’ steps execute the action method on the controller, and the ‘Then’ steps verify things like the ActionResult and the ViewData.
You absolutely need unit tests to verify the behaviour of the lower level components, but the point is that the test scenarios that you write and the expected behaviours are all ‘pulling’ from the requirements in the defined BDD scenarios. If at any point you’re unsure of whether you have the correct set of test cases, you should refer back to the plain English scenarios, read through the expected behaviours, then ensure that your unit tests are set up to verify the correct thing.
This really means that the BDD automated acceptance tests and unit tests do both sit well together. The difference is that the BDD tests give the overall context that you’re working to, and provide a focal point about what you should be testing and why.
Language used in unit tests
BDD talks quite a lot about the importance of language used, and how the word ‘test’ implies checking something after the event. Unit tests are all about defining expected behaviours, so the word ‘should’ is much more appropriate. I have to admit, initially I quite seemed like a pretty unimportant distinction to me, and I didn’t quite get it. However I’m now totally convinced.
Previously I would have pretty much created a test fixture per class, and the unit tests names would have probably ended up being oriented around the technical implementation. For example, testing an application service might result in a test fixture called SecurityServiceTestFixture.
I’ve taken to creating a test fixture for each action or process, then starting each unit test method with ‘Should’ to express a particular facet of the expected behaviour. Using the same example, I might create a fixture called RegisteringANewUser and the unit test would be called something like ShouldSendAnEmailToVerifyTheUserEmailAddress.
Although this is quite a subtle distinction it makes it much easier to work out what test cases there should be, and to read back through and understand exactly which behaviours are being tested. It’s also easier to read the original scenario definition, read through your unit tests and get a sense of whether everything is covered.
Composition of a unit test
The actual way that a unit test is put together is pretty much unaffected – you’ll generally go with the same arrange, act assert pattern. The only change that I’ve really had to make is organising the test fixtures, and the language that I use for the test methods.
BDD Workflow
Putting all of this together gives you the following kind of workflow…
- You start with the Gherkin based scenarios defined in plain English
- You bind each scenario step to an executable method, and test your user interface
- During this process you use interfaces for any dependencies, and mock these to verify the UI behaviour
- Once the UI tests are passing, you look at each dependency and write lower level unit tests to cover the expected behaviours
- For each dependency, you look at any further dependencies and write unit tests to cover these additional components
- Work to get each unit test passing
- If at any point you get confused about which unit test cases to write, refer back to the scenario definitions to have a clear set of requirements about the expected behaviours
- Either move on to the next scenario, or define some more scenarios
-
Using Specflow to test a form post scenario with ASP.NET MVC 3
I was working on a feature recently that began with a scenario in Specflow, something like this…
Scenario: New password min length Given I have entered a password with only 5 characters When I hit save Then I see a validation error against passwordSo, first off I’m going to need to simulate a value being posted to an action method in the form collection. The simplest approach would be something like this…
[HttpPost] public ActionResult ResetPasswordSubmit(string password) { }However, it doesn’t really feel right to put the business rules around password validation directly in to this action method, as there may be other places in the application where a user can change their password. A better approach would seem to be implementing the validation rules as Data Annotation attributes against the model class. The method then becomes something like this…
public class SecurityController : Controller { private readonly ISecurityService securityService; public SecurityController(ISecurityService service) { this.securityService = service; } [HttpPost] public ActionResult ResetPasswordSubmit() { var user = this.securityService.GetSignedInUser(); if (this.TryUpdateModel(user, new string[] { "Password" })) { // save user } } }Working with a model class that looks a bit like…
using System.ComponentModel.DataAnnotations; public class User { [StringLength(20, MinimumLength = 5)] public string Password { get; set; } }So what would happen now is that the browser would post a single value in the form collection (Password). When TryUpdateModel is called, the framework will use a model binder to map the request information onto the model properties. The model binder to use can change according to the type being mapped, but in this case the DefaultModelBinder will be used.
The model binders need to make use of information from the request (such as posted form values, querystring etc). Value Providers provide an abstraction around this, and the framework ships with various providers to interrogate the different types of request information. In our example, the FormValueProvider would map the Password value from the form collection onto the Password property of our model class. As part of this process, the DefaultModelBinder will apply any validation rules set up via Data Annotation attributes, and add any validation errors into ModelState.
Time to get started with our unit test. With SpecFlow, the scenario is defined in a plain English language based on the Cucumber DSL. When you save the scenario, Specflow will generate a test fixture that includes a test method with the scenario name – in our case NewPasswordMinLength. The test method will attempt to call a method for each individual step in the scenario based on binding attributes applied to the methods.
We can start by adding a new item, and picking Specflow Step definition. To map the scenario steps in our example would like this…
[Binding] public class ResetPasswordSteps { private ActionResult result; private readonly Mock<ISecurityService>; private SecurityController controller; private User user; [BeforeScenario] public void BeforeScenario() { this.securityService = new Mock<ISecurityService>(); this.controller = new SecurityController( this.securityService.Object); this.user = new User { Id = 1 }; this.securityService .Setup(s => s.GetSignedInUser()) .Returns(this.user); } [Given(@"I have entered a password with only 5 characters")] public void GivenIHaveEnteredAPasswordWithOnly5Characters() { ScenarioContext.Current["Password"] = "Foot"; } [When(@"I hit save")] public void WhenIHitSave() { // todo: simulate the form value being posted this.result = this.controller.ResetPassword(); } [Then(@"I see a validation error against password")] public void ThenISeeAValidationErrorAgainstPassword() { var view = this.result as ViewResult; Assert.IsNotNull(view); Assert.AreEqual("ResetPassword", view.ViewName); Assert.IsFalse(view.ViewData.ModelState.IsValidField("Password"); } }First we set define a method decorated with the BeforeScenario attribute. This is a Specflow attribute that indicates the method should get executed before each scenario. This can be used to carry out any initialisation required. In this case, I’m mocking the SecurityService dependency and setting it up to return a dummy User object when the GetSignedInUser method gets called.
Executing the NUnit test would evaluate each step in the written scenario, discover these methods based on the binding attributes, and execute them in turn. Any state information that needs to be preserved can be either stored in private fields or on the ScenarioContext object.
The bit missing is how to simulate a form value being posted in the unit test. Remember the binders will use ValueProviders to get information from the request, so this is the piece we need to mock or simulate. To get this working, we would need to add the following code…
[When(@"I hit save")] public void WhenIHitSave() { var form = new FormCollection { { "Password", (string)ScenarionContext["Password"] } }; this.controller.ValueProvider = form.ToValueProvider(); this.result = this.controller.ResetPasswordSubmit(); }Here we are using the FormCollection class to simulate values being posted, and setting the controller to specifically use this value provider for binding scenarios, instead of the default set of providers.
At this point in time, we get a null reference exception running the test, as TryUpdateModel assumes that the ControllerContext property on the controller is available. To get the test working we need to mock this, so back in our initialisation method we add a few lines…
public void BeforeScenario() { this.controller = new SecurityController(this.securityService.Object); var httpContextMock = new Mock<HttpContextBase>(); this.controller.ControllerContext = new ControllerContext( httpContextMock.Object, new RouteData(), this.controller); this.user = new User { Id = 1 }; this.securityService .Setup(s => s.GetSignedInUser()) .Returns(this.user); }That’s all we need. To recap…
- We started by writing a plain English scenario in Specflow
- We created a class to contain the step definitions and added binding attributes to map the Specflow scenario steps to the right methods
- We added a method to run before the scenario to initialize the controller, mock the dependencies and provide a ControllerContext
- In the WhenIHitSave method, we initialized a FormCollection with simulated form values and set the ValueProvider on the controller to make use of this
- In our ‘Then’ method we assert that the view was returned with a ModelState error against the Password field
- The end result is an executable acceptance test (by default this will be NUnit unless Specflow is configured otherwise)
All mocking examples have used Moq which is awesome.
-
Starting work on TeamBrain, an open source knowledge repository for project teams
I’m increasingly finding that all of the information and knowledge that I want ready access to won’t quite fit in my head at one time. Most technical projects that I’ve worked on over the years have suffered from the same problem but amplified across a team. Typically the team will rely on the knowledge of individuals, and create quite a critical dependency on key people. There are good practices which can reduce the risk of this, such as pair programming, and documenting system behaviour with automated tests, but it still helps to have instant access to pretty much anything you need to know about a project. The fundamental problem is that documentation is not much fun, and very quickly gets out of date.
Obviously there are solutions to this problem, the foremost being to set up a project wiki. However I’m quite fussy about design and interaction, and the way that software feels when you use it, and I’ve yet to find a wiki product that makes me feel good. I want something that is addictive and satisfying to use, that engages you and makes you want to work with it. The idea being to build a multi-tenant application that can host project knowledge for teams.
Based on this I’ve started work on TeamBrain, hosted on Codeplex. Feel free to grab a copy of the source and talk to me as it develops. I have some time off work so will be trying to flesh it out over the next few weeks.
I’m also taking the opportunity to try out a few new technologies and things I’ve wanted to take a look at for a while. The one I’m most excited about is BDD (Behaviour Driven Design). I’ll be running the project by defining features and scenarios in SpecFlow, and having all of the unit tests and behaviour pulling from the defined scenarios. If you want to learn more, I suggest starting with this screencast which gives a really great introduction. I’ll post some examples and hints as I learn along the way.
-
Testing SyntaxHighlighter for code snippets
I’ve been reading this article from Scott Hanselman which details how to use a combination of the PreCode plugin for Windows Live Writer along with Syntax Highlighter to author and nicely present code snippets. Syntax Highlighter is a client-side solution using javascript and CSS to add the appropriate hooks and styles to an authored code snippet. This avoids a lot of the guff that gets injected by many of the solutions out there. I’m now going to include some random code to check everything is looking sexified…
[Given(@"I make a mistake and don't copy all of the characters")] public void GivenIMakeAMistakeAndDonTCopyAllOfTheCharacters() { this.registrationMock .Setup(r => r.ActivateUserFromToken(It.IsAny<string>())) .Throws(new InvalidActivationTokenException()); } -
Recommended reading for December
C# In Depth By Jon Skeet
I’ve been waiting a while to for the updated edition of C# in Depth by Jon Skeet which is now on sale and covers C#4. I’ve read the first couple of chapters and would really recommend it regardless of how much experience you have with C#. It’s already helped me with some very clear explanations for concepts that can be a little tricky to express even if you understand them already. One particular explanation that I liked was to distinguish between delegate types and instances, and to think about a delegate type as an interface for a method – so a contract that the method has to fulfil. I’m quite sure that there will be a lot that I’ll get out of reading the rest of the book.
CSS3 For Web Designers by Dan Cederholm
This is the second book to be published by A Book Apart and should definitely be worth checking out. I think it will really help to provide practical advice about where you can safely start applying elements of CSS3 right now. I’ll post more when I’ve got hold of a copy.
