Skip to main content

Posts

Showing posts from 2011

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 m…

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.Turn off automatic updates for your browser/pluginsSet your IIS (or equivalent) app timeouts to zeroCreate a base Selenium Fixture for use in your testsUpdate to the latest version of SeleniumWarm up your apps prior to testingDitch Selenium - test at the API levelTurning 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 t…

The Best Code is Written Twice

Recently myself and two colleges completed a new feature in an afternoon's programming session. Despite this we ended up binning the feature after all agreeing it was horribly complicated and in turn would cause far more problems down the road than it would solve.We decided to rewrite the feature again, but applying all the lessons we had learned from the first attempt. A recent blog post by royvanrijn on this very topic made me appreciate what we had done. He points out that the best code occurs from several attempts, and unlike what people may expect, the repeat attempts need not take the same amount of time to deliver as the initial attempt.The second time you write the code, it'll only take a fraction of the time it took initially.This principle of repeating a task made me think of when I was decorating my old bedroom. I helped partake in the difficult task of wallpapering the ceiling. Prior to this I had experience wallpap…

Smalltalk Conversion mapped to C#

Lately the team has been making some rather drastic changes and re-designs to our codebase in an attempt to minimise friction to change. In other words, we've identified areas that are painful or tedious to work in and have hopefully rectified them by re-writing the code. The proof of this should be felt as we begin adding new features, the newly improved code is certainly faster and more optimised.Regardless, one area that remains troublesome in my opinion is object mapping (or the correct term of conversion) code. While I've not personally been involved with this reworking of the codebase, I have recently just finished reading Kent Beck's - Smalltalk Best Practice Patterns. Many of the developers I follow on Twitter have been blogging about this book and I figured it was time to give it a go. After all it gets massive praise whether or not you use Smalltalk. While reading this book a few key points regarding object conver…

Ten Things a graduate will experience during their first year at Codeweavers

KanbanThe importance of value and flow are the heart of day to day running at Codeweavers. During my time I've read books such as The Goal and The Toyota Way in which the likes of the Theory of Constraints and the Toyota Production System are discussed. I was also lucky enough to visit Toyota to see these practices in play.Pair ProgrammingA big part of our day to day work is done via pair programming. There are huge benefits to pair programming, but being a graduate within an organisation where pair programming is the norm is a huge benefit. Graduates usually enter the workplace with no experience in the business domain and limited technical experience. Being set loose initially would be a disaster. Graduates therefore typically shadow other developers often spending anywhere from weeks to months until they able to commit any code without sup…

Mapping Objects via TDD

Why we map?Many times at Codeweavers we often have tasks which involve mapping between various objects. It is no secret that I dislike such tasks. The reason we map between objects though is actually a good thing as pointed out by several developers. Mapping means our components are less coupled. For example, we can write one feature and then simply map different web services to use this feature. If we chose not to map to a common object we would need to re-implement this functionality for each service. Therefore not only do we decouple our code, but our codebase is much DRYer.What ways do we do it?One approach is a test per property. One developer will write a failing test for a property (accessor), while the other developer writes the code to make this test pass. During this process the keyboard flicks back between each developer very rapidly, in fact most of the time when writing a property per test is spent sliding the keybo…

Unit Testing C# attributes

For a recent coding session I needed to handle an exception being thrown when some Json was incorrectly bound to a view model. With the framework we were using (ASP.NET MVC2) I was unable to handle the exception at the controller level, nor could I handle it at the "global" level when the framework carries out its bindings. Another way ASP.NET MVC handles exceptions is via attributes to catch errors you specify. The resulting exception is strongly typed and then can be passed into a view, from which you have full control of what to do. Typically we would log the error, display a friendly message and so forth.In the past these attributes have been simply applied without a test - the general consensus being this was a framework specific thing which had no value in being tested. I agreed with those statements up until several minutes ago. Having fixed a defect in which the user was not seeing a friendly error message I carr…

Getters and Setters are Evil

Update: There is a new version of this post.I've been programming with OO languages since I was seventeen yet in the last week I've had what is without doubt one of the biggest learning experiences since I've started.Numerous developers that I've worked with claimed that we aren't doing OO properly. By we I mean software developers as a whole. Their argument being having all your code defined in classes does not mean you are obeying OO principles. By this they are often referring to the "Tell Don't Ask" principle. One particular individual at Codeweavers introduced me to idea that getters and setters are evil. While not true at face value, this statement is to get you thinking about what you expose to the outside world. Consider one of the founding pillars of OO programming; encapsulation.Encapsulation states that an objects internal state should be just that, internal. If we want a object to do something we shoul…

Mock Roles not Types

"if it feels wrong, it probably is" - numerous Codeweavers' developersThe framework we use at Codeweavers is the excellent Moq, therefore when something is difficult to mock we are forced by the framework to write an adapter. We use an interface for testing, then create a concrete type which simply invokes the hard to test code such as static code, third party libraries and resources that are expensive to set up. There are some ways ways in C# to get around this, but they involve black magic and should be avoided at all costs unless you are deeply entangled in legacy code. A refactoring would be preferable over hard to test code.The process of writing an adapter around hard to test code is a standard practice, we do it all the time as we are forced to by the unit testing framework. Some frameworks we use at Codeweavers such as ASP.NET MVCare designed with testability in mind, so unlike scenarios where you cannot test code…

MBUnit to NUnit

Over the last few weeks we've ported our tests from MBUnit to NUnit. This was done as after a quick spike it was seen that NUnit tests run almost fifty percent quicker. For example our common projects' test time went from around 40s to around 20s on average.This whole process was no easy task. Initially our largest project was converted by the whole team. We split into pairs/individuals and tackled a test project each. Working in this manner we could commit after each project, meaning at any one time the build was only fractionally broke, rather than completely unbuildable. Previously we tried a big bang approach but after several thousand errors, we quickly reverted. After each commit the tests were gradually moved over. This took around an hour or so, and therefore our allocated dojo/technical dojo time for that week was used. For the remaining projects an ad-hoc approach was taken. The first pairs to work on a project would …