Last week, Wednesday 20th Feb, I presented at the Brighton Web Development Meet-up. My talk was an introduction on using Selenium WeDriver, starting out with the basics, leading into introducing the page object model and finishing with an example on how to use a single suite of tests on multiple websites. The demo code and slide deck can be found on my GitHub account. The room was pretty packed with about 25-30 people and a . . .
Today I realised that I’d forgotten how spoilt I am using Resharper and dotCover to run my unit tests. Put another way I’d forgotten how badly Visual Studio plays with any other unit test frameworks other than MS Test! I’m used to and really like the fluent API style of NUnit’s Assert.That(…) syntax so having to fall back to MS Test always feels like a step back. If you ever find yourself in a situation . . .
Following on from my original post of learning how to put JavaScript together it’s been a really productive week. Have I managed to write JavaScript that’s easy to test? No, but I’ve wrapped up some reasonably complex logic into a component that can have some of its functionality tested! At the moment I’ve settled on QUnit as my JS unit testing framework and have a couple of tests verifying the default values of exposed properties . . .
After many years of trial and error / practise I feel fairly happy that I can write clean, testable .NET / C# code, which is free of any external dependencies which traditionally make unit testing harder. It’s fair to say that I’m a convert to TDD; having implemented it on two separate commercial projects and seen the benefits of the improved maintainability of the codebase over time. But what about Javascript? Thanks to Selenium and . . .
When I first started looking into Windows Workflow one of the first things that I liked about it was how it separated responsibilities. The workflow was responsible for handling the procedural logic with all its conditional statements, etc. Whilst individual code activities could be written to handle the business logic processing; created in small easily re-usable components. To try and realise my original perception this series of blog posts will cover the unit testing of . . .
In this post, we will extend the query functionality to handle stored procedures with parameters. To do this we need to create a new query type interface with an example implementation: Now that we have the ability to create stored procedure queries we need something to handle them. To do this we need a concrete implementation of the interface “IHandleAQuery”: Finally, we update our factory to handle the new query interface and return the correct . . .
In part 3 we created a SQL repository object that took a populated instance of IQuery to select/return an enumerable list of objects. A limitation of the repository was that the query had to be text-based, it couldn’t handle stored procedures and/or parameters. By incorporating an abstract factory pattern we can extend the functionality to handle different types of query. The original code inside “SqlRepository.Get(…)” needs to be changed from: To: The static factory class . . .
In Part 1 of this series, we started with a basic Data-Reader / SQL Connection/Command pattern and illustrated how it is possible to abstract the parsing of the Data Reader into a standalone object that can be fully unit tested in isolation of the calling code. In Part 2 of the series we made a very simple optimisation to the “DataReader” convertor and updated the tests to capture/verify the changes. In part 3 of the . . .
It seems that a common aim when first starting out in unit testing is to obtain 100% code coverage with our unit tests. This single metric is the defining goal and once obtained a new piece of functionality is targeted. After all, if you have 100% code coverage you can’t get better than that, can you? It’s probably fair to say that it’s taken me several years and a few failed attempts at test-driven development . . .
In Part 1 of this series, we started with a basic Data-Reader / SQL Connection/Command pattern and illustrated how it is possible to abstract the parsing of the Data Reader into a standalone object that can be fully unit tested in isolation of the calling code. In Part two of the series, we will highlight a very simple optimisation that can be made to the “DataReader” convertor and the required update to the tests to . . .