Warnings as Errors

One thing that annoyed me when starting at Codeweavers was the amounts of warnings that would occur during a build of any of our projects. Seeing the build progress only to spew out a screenful of text was something that did not sit right with me. I was not the only one who felt this was wrong, but as there was so many warnings in some cases, it was easier just to pretend they were not there. After all everything was working fine.

The broken window theory is very much in action here. During our last standards review we decided that there should ideally be zero warnings per project. It is worth mentioning that most of our warnings were just that, warnings about something that was not really a major issue. Warnings such as unused variables and so on fall into this area.

On the other hand, while 90% of our warnings were ignorable, there were a handful which were rather important. Examples such as referencing different versions of required .dlls. Warnings like this are extremely helpful. It would be wrong for these to be hidden among a block of less serious issues. Warnings such as these once visible, can save hours of painful debugging.

Some of our projects had a fair few warnings – in the region of fifty plus. In order to begin tackling these larger projects we started slowly. If in a single day I would have removed a batch of warnings, this was a step in the right direction. After a week or so all our projects were void of warnings.

The next step was to make sure we do not go back to having larger projects with warnings galore. To prevent this I enabled “Treat warnings as errors” within Visual Studio. This is per project setting and can be found under the “Build” tab. Do note that you must enable this for “All Configurations” otherwise any settings you change will only apply to Debug/Release builds.

Enabling warnings as errors

I like this feature of Visual Studio emmensely. Having the compilier do as much work as possible – in this case check for warnings is similar to a tip found in Working Effectively with Legacy Code. Here the concept of “leaning on the compiler” is introduced. In other words you introduce an error in order to show you the usages of a piece of code – this is stark contrast to manually searching for the code in question.

The end result of this process is now during a build, if any warnings occur, the build will fail. The build will report where the warning is, along with why there is a problem. While this is great in theory it can cause some slight pain when developing, as you may comment out some code to experiment only to find the build failing due to unused variables. Despite this treating warnings as errors has been a great help. Recently we have solved some pretty serious issues with regards third party dependencies all thanks to treating warnings as errors.

The idea of allowing the computer to do as much work as possible applies to all languages. For your compiler/interpreter etc… there will be an option to apply warnings. This is not a specific language feature.

Image courtesy of http://freeaussiestock.com/free/Australiana/slides/beware_of_snakes.htm

Write Unit Tests? Start deleting them.

A recent blog post by Steve Klabnik concluded with a statement about tossing unit tests if you have end to end tests covering the code in question.

Don’t be afraid to change the tests! As soon as you’ve verified that you’ve transcribed the code correctly, don’t be afraid to just nuke things and start again. Especially if you have integration level tests that confirm that your features actually work, your unit tests are expendable. If they’re not useful, kill them!

A few people on Twitter found this odd, and I’d have included myself in this statement a while back.

@isaacsanders @avdi seeing @KentBeck delete unit tests during his screencasts changed my TDD process forever.—
Shaun Finglas (@F1nglas) January 21, 2012

Kent Beck’s TDD screencasts changed my view on deleting unit tests however. During the later videos, he actually deleted some tests. Pretty much all TDD resources don’t really mention this. One of the key points beginners learn is that if you break any tests, you’ve introduced a regression. This is not always the case. If you follow the rule of never deleting ANY tests you encounter you are going to be stuck with someone else’s implementation forever. Likewise unit tests are there to drive design, not enforce how something works. I remember discussing deleting unit tests with my work colleagues and finding Kent’s videos pretty shocking at the time. I mean deleting unit tests!?

The more I do TDD, the less this statement becomes so jarring. For example.

public Result DoSomething()
{
    // Implementation here.
    // Pretty straightforward.
    return result;
}

Consider a test for the above behavior, such as we get the result back in a particular state. Pretend the logic is rather simple, and it does not warrant a separate object. Any other developer should be free to come along and change the internals of this method. As long as we get a result back in the correct state, the test should be valid. The test should not care that we are using strings, lists or whatever internally.

Occasionally I find tests like this hard to pass. In other words, I feel like the logic is correct yet the test fails. Maybe I’m using a new language feature, or a language feature that seems to be not working as I expected. If so I’ll break out a new unit test that tests the implementation. Such tests are often refereed to as learning tests. Here with a smaller focus I often become aware of what I’m doing wrong. Following Kent Becks example, I ditch the test after and move on.

I feel this sums up my feelings nicely.

@elliottcable @F1nglas @isaacsanders @kentbeck let them guide you to a design but don't let them hold you to a design.—
Avdi Grimm (@avdi) January 21, 2012

I and others are not saying bin every unit test you have that is covered by end to end tests. Unit tests are great, you can run hundreds in a matter of seconds. They have their place as part of the development process, but do not find yourself working against them. However I am saying you should delete any test which relies on implementation details. I am saying bin any test which does not make sense. I am also saying bin tests as part of a refactoring session as long as you have test coverage higher up. If you don’t have test coverage such as acceptance tests, you cannot be sure you have not broke anything after the refactor.

LOG EVERYTHING

This post was originally conceived back in mid 2011, starting a new project made me think back to this event, hence the post.

Any developer worth their salt will know what logging is. You could argue there are two types of logging, either developer logging or auditing. Developer logging would be what we log when something goes wrong. Using the results of this logging we can track down what went wrong, and put fixes in place to stop this event from occurring again. If this logging fails, or logs the incorrect thing it is not the end of the world. Due to this, I generally do not care for testing such scenarios. The code should behave the same with our without this logging.

Auditing would come under logging which as part of the application needs to be carried out at all times. Consider visiting a cash machine. When withdrawing fifty pounds, you want to make sure your bank logs this in case anything goes wrong. This sort of logging is crucial, and must work and must log the correct data. This is considered a feature, therefore this should be tested as it is part of the behavior of the application.

When I think back to my first few years of programming my code was littered with logging. In the early days after each statement, variable and function I would print out what happened, along with any errors that happened. In fact I’d say that everyone starts out like this. The strange thing is as we get better, the logging becomes less and less. Rather than the first class citizen we relied on in the early days, logging is seen as boring. The problem with treating logging code as a second class citizen is that when things go wrong, it can be very difficult or near impossible to track down what has happened. When you realise you need logging, its often too late. You will need to redeploy the application and wait for the problem to expose itself again.

Back in 2011 we had a difficult problem to track down. The dreaded “OutOfMemoryException“. Being the cocky developers we were, we decided to add the logging last. After all, it was there for when things went wrong. We never planned things would go wrong, after all it “worked on my machine“. After redeploying the application with logging we managed to track down roughly what was going wrong, and in turn began to resolve the problem. Had we added this logging initially, we could have resolved this problem in half the time.

The lesson I learned here was simple. Any time you have an error, log it. If the logging is not in place, we add it. Creating a new application? In the first iteration(s) make sure some form of logging is in place. I believe by following this simple rule any future issues can be handled easier. Logging should be a first class citizen regardless of purpose.

Around the same day I had this revelation, the image above popped into my Twitter feed. Image via @olafurw

6 Ways To Speed up Selenium Tests

Having finally achieved more stable end to end tests via Selenium, we figured it would be worth while sharing how we achieved this. The following are six steps we’ve found that you can do to make Selenium tests more stable.

1. Turn off automatic updates for your browser/plugins
2. Set your IIS (or equivalent) app timeouts to zero
3. Create a base Selenium Fixture for use in your tests
4. Update to the latest version of Selenium
5. Warm up your apps prior to testing
6. Ditch Selenium – test at the API level

Turning off automatic updates seems like a no brainer, but after a fresh install we forgot to do this once and spent some time figuring out why Firefox would not load on the CI server. It turns out that the “You’ve just updated” window was blocking the test from continuing as it had stole focus.

The second point is with regards caching and the general responsiveness of your application. We have a few applications that take about thirty seconds to fully warm up due to the huge data set they rely on. If we can build this cache once, then store it for as long as possible, subsequent hits to the app should be instant. In other words, we try to mirror our live environment as much as possible.

Our custom test fixture attribute enables the ability to modify all Selenium tests in one go. We found that from 3am to 5am our databases undergo maintenance, therefore we do not run our regression tests during this time. All this took was one change within the attribute to apply to all tests. For example:

public class RegressionTestFixture : TestFixtureAttribute
{
    public RegressionTestFixture()
    {
        Category = "Regression";        
        OnlyRunTestsWhenDatabaseIsActive();
        // Etc...
    }
}

We simply inherit from NUnit’s TestFixtureAttribute and use this custom attribute rather than the standard TestFixture attribute. The inheritance is required to ensure that third party tools such as test runners still work as expected.

Previously we were using Selenium 1.x with Sauce RC. Having ditched this and upgraded to Selenium 2.x we’ve been able to update our browsers to the latest versions, in turn this allows improved speed and stability when runing the tests.

On our local development machines the application you are working on is often in memory, meaning subsequent hits should be much faster after all dependencies are loaded and cached. The issue we discovered on our CI server was that after a fresh build of the whole codebase, the initial hits to the applications would be very slow. To combat this we added a warm up step to our build. Just before the tests are run we would perform a HTTP GET to invoke our applications start up processes. This added somewhere in the region of thirty seconds to the build, but the increase in stability is staggering. No longer will Selenium report timeouts.

Finally the fastest end to end tests come from not using Selenium. Ditching the browser completely and testing as high up in your API is the quickest, and most stable solution. Combining this thinking, with a handful of dumb Selenium tests that just check for the likes of 404s seems to be the most optimal solution currently.

Having done these at some point over the past few months we’re starting to get to a more stable point with our Selenium tests. We’ll be looking to take this forward with future tests and hope to enjoy continued stability.

How to Achieve More Stable End to End Tests

Recently myself and another colleague wrote an acceptance test for a feature that had yet to be implemented. For this end to end test we used Selenium, after all we wanted to test the whole feature so this made sense. Our test performed some simple user input, performed a calculation and checked the response. The problem with the test was it was very brittle. If the application had not recently been used, the massive data set the application relied on would not be cached.

To get around this we added a few Thread.Sleep() statements into the test. This worked rather well for the majority of test runs, but sometimes these pauses were not long enough. On the other hand sometimes the data was cached, meaning these sleeps would be unnecessary. One resource which has recently done the rounds was regarding useful advice about using WaitForPageLoad() and WaitForCondition(). WaitForCondition will only execute once a condition has been met, such as a element becoming visible. This meant that for the times when the dataset was in memory the test would be executed immediately, while the times when the data was being loaded, the test would simply wait until the test was ready to move on. This was a very simple, yet highly effective tweak to our tests. The execution time went from roughly thirty seconds, to just less than ten seconds in one case.

This was not the end of the battle to achieve more stable Selenium tests. Some of our tests were still rather flaky. Some mornings we would enter work, notice the red build and discover that the several failed tests were down to Selenium timeouts. During the daytime however, we rarely had these issues. In order to fix these problems I increased the frequency of builds. The idea being the more we run our builds the more chance we have of spotting the errors. After all, if something was to fail at 2am, I am unlikely to care. 2pm however, and the team will be all over it. By making the problem more visible, we would be forced to fix the outstanding issues.

The aim was to make the tests as fast as possible, while maintaining stability. One thing the excellent Growing Object-Oriented Software (Goos) touches on is the aspect of not needing to perform end to end testing at the GUI all the time. The benefit of not touching the UI is huge. Your tests are faster, they’re more stable and a heck of lot easier to write. The other nice benefit of testing from an API point of view, rather than the browser is it forces you to decouple your app from the views. If you’re not writing fat models and skinny controllers, you’ll have adapt in order to test as much of your application as possible without hitting the UI.

What about the remaining part of your feature that is not covered by the application? I like to imagine this part as the tip of an iceberg. As this area is small enough the actual UI testing you need should be minimal. So here we can let Selenium do what it is good at. Click things. Selenium is great at this. All you need to do at this level is check for 404s, incorrect page titles and a few other mundane aspects of the UI. There should be no need to check if your actual application is correct at this level. For correctness, you should have a large suite of fast, isolated, unit tests.

Another point to consider is how often your view actually changes, in comparison to your actual underlying API. A designer should be free to move things, rename content, add images and so forth without breaking tests. As long as there is a calculate button somewhere on the page, and said button takes you to a result page, who cares about everything else? Likewise the code underneath can be consistently changing behind the scenes, as long as the API remains constant, our tests should always be valid.

For the technical low down on some of the ways we are achieving more stable end to end tests, check out six tips to speed up Selenium tests.

Image courtesty of Natalie Lucier

Postcode District Kata

We’ve recently had a task of importing some new data to one of our insurance related applications. Without boring you with the technical details, the algorithm relies on the postcode district to apply a rating factor to the overall insurance premium. The change came when our customer asked to alter premiums based on areas.

To get to this point we decided to auto generate a C# dictionary (hashtable) of postcode districts that would be used during compilation and stored in memory. The file we were provided came from a Word document that in turn went through Google docs, and finally Open Office. The end result was something similar to the snippet below. Please note the inconsistent tabs and spaces, as well as upper/lower case conditions.

The task is simple. Write some code that will parse a file containing lines of text in the format of district, condition and value. The code should accept a string representing each individual line and return a string representation of a C# dictionary. For example given the first line in the input file below, the output would correspond to the first dictionary underneath.

• Column 1 contains the district, either one or two characters.
• Column 2 contains the condition, either “All” or “Ex Below”. Exclusions apply to the district that was last processed. Exclusions should be stored as areas e.g. in the form {DISTRICT}{AREA} while conditions that apply to all should be stored in the form {DISTRICT}.
• Values that are linked to a district/area are in the range one to five

Rules

1. Copy & paste the input file to maintain the “formatting”
2. Handle any number of tabs between columns.
3. Handle any number of spaces between columns.
4. Handle any number of tabs and spaces between columns.
5. Handle any case of conditions, eg. Ex below or EX below
6. Handle empty lines – no tabs/spaces
7. Must be able to read the whole input file in one go.

Input File

AB		All				1

AB		4				2

ST		3-5			5

ST		ex below			4
		26				3

S	Ex below	        4
	26/30			3

B		Ex below			2
		45-47				3

C		EX BELOW			4
		26/28-31			3

DY		1/2/4				5

DY    1/2/4                             5
      5-6                               3

DY		1/2/4				5
		5-6				3
		10-12				2

Output Per Line

{{"AB", 1},}

{{"AB4", 2},} 

{{"ST3", 5}, {"ST4", 5}, {"ST5", 5},} 

{{"ST", 4}, {"ST26", 3},}

{{"S", 4}, {"S26", 3}, {"S30", 3},}

{{"B", 2}, {"B45", 3}, {"B46", 3}, {"B47", 3},} 

{{"C", 4}, {"C26", 3}, {"C28", 3}, {"C29", 3}, {"C30", 3}, {"C31", 3},} 

{{"DY1" 5}, {"DY2", 5}, {"DY4", 5},}

{{"DY1" 5}, {"DY2", 5}, {"DY4", 5}, {"DY5", 3}, {"DY6", 3},}

{{"DY1" 5}, {"DY2", 5}, {"DY4", 5}, {"DY5", 3}, {"DY6", 3}, {"DY10", 2}, {"DY11", 2}, {"D12", 2},}

File Output

The final test will be to process the whole file in one go. In the programming language of your choice this would be a case of reading all lines within the input file and invoking the code you wrote for each line. The end result should be:

{{"AB",1},{"AB4",2},{"ST3",5},{"ST4",5},{"ST5",5},{"ST",4},{"ST26",3},{"S",4},{"S26",3},{"S30",3},{"B",2},{"B45",3},{"B46",3},{"B47",3},{"C",4},{"C26",3},{"C28",3},{"C29",3},{"C30",3},{"C31",3},{"DY1",5},{"DY2",5},{"DY4",5},{"DY1",5},{"DY2",5},{"DY4",5},{"DY5",3},{"DY6",3},{"DY1",5},{"DY2",5},{"DY4",5},{"DY5",3},{"DY6",3},{"DY10",2},{"DY11",2},{"DY12",2},}

The Best Looking Visual Studio Theme

One of the most popular posts we have was our customised Visual Studio theme. Here is the new theme updated for Visual Studio 2010.

Our current VS theme

There’s always lots of buzz around whether or not like or dark themes are better. Some people claim that darker backgrounds are easier on the eyes, and I personally agree with this statement.

That being said, if you know of a better looking theme let us know in the comments.

Download the updated theme  (minus all other VS settings)