We wouldn’t dream of running an A/B or Multivariate test without a solid hypothesis in place. These little statements are the tiny hearts that power an idea through to completion.
But what is it about this statement that makes it so invaluable? And how specifically has it helped us? I’m hoping this article will give you an answer to these questions, as well as convince you to use them in your testing program (if you’re not already doing so, that is).
Best of all, I’ll be using a real example as a case study! Continue reading
Testing React components has become trivial as more and more of them are now stateless functions.
The new shallow renderer and tools like Enzyme make it possible to render a component “one level deep” when testing, without even rendering it in some sort of DOM, while still having a great api to traverse the components’ output and assert facts on its behaviour.
Given all these great tools that we have, what happens when we have a container component that renders sub-components (child components) based on some sort of rule/logic?
How do we handle those dependencies to keep our unit tests free from dependencies?
Debug all the things!
I’ve been spending quite a lot of time render checking and debugging various new features recently. Whilst unit and acceptance tests are essential for ensuring an application functions correctly, rendering is an important thing to check too and often needs a variety of methods of testing to ensure pixel perfect results on all media. Continue reading
Often a situation faced by coders, especially when following test-driven development, is the writing of very similar test cases, changing only in, for example, the expected and actual values, along with some set up parameters. We often end up writing dozens, nay hundreds of near identical test cases, and end up with a test class that looks that it has suffered from a terminal case of copy-paste. This blog post shows a little-known technique for making this sort of test class a little more readable using the nUnit TestCase attribute.
Here at thetrainline.com we have several useful online tools for helping our customers plan and manage their train travel, including Train Times and Live Departure Boards. We recently changed the way we build, test, and deploy these kinds of applications to enable us to release new features much more frequently and easily; in fact, we shortened the deployment cycle from one deployment every few months to multiple deployments per week. These changes have produced a sea change in team culture, with a marked increase in product ownership by the team. This post describes what we’ve done so far, and where we want to go over the coming months.
We in the engineering team at thetrainline.com hold an ‘open day’ every six months to share what we do with other (less ‘techy’) teams in the company. The most recent Engineering Day, in February 2013, saw members of the HR, Legal, Commercial, Marketing, Finance, and other teams (plus our Exec) attend presentations and demonstrations from members of our tech teams covering: web performance, service versioning, deployments, infrastructure automation, testing, ticket retailing, and even a workshop on ‘How to build your own website‘. Continue reading
Recently, we were fortunate to be joined by Steve Freeman (@sf105), co-author of Growing Object-Oriented Software, Guided by Tests, and one of the early practitioners of Test-Driven Development (TDD). Steve facilitated a discussion at our weekly dev session (aka Burrito Club) on how tests can and should be used to help shape the growth and evolution of software, particularly the use of Ports and Adapters to make testability a first-class concern.