RevealJS - HTML Presentation Made Easy

If you are looking for an alternative presentation authoring tool then have a look at revealjs.

reveal.js is a framework for easily creating beautiful presentations using HTML. You'll need a browser with support for CSS 3D transforms to see it in its full glory.

I've used it a couple of times now in several workshops and the crowd love it. There is a certain degree of html knowledge required to use it, but the results are worth it. Checkout their site to see a presentation in action.

http://lab.hakim.se/reveal-js/#/

One of the things I love about revealjs is the ability to broadcast presentations and update any viewers device with the page you are currently presenting (Multiplexing). It uses Socket.io server to broadcast events from the master to the clients. See a demo at http://revealjs.jit.su/.

GTAC 2013 - Videos now up

I wasn't lucky to get an invite to this years GTAC, but the videos look good.

See the conference here:

http://www.youtube.com/playlist?list=PLSIUOFhnxEiCODb8XQB-RUQ0RGNZ2yW7d

Versioning Test Code

In some development environments it is quite common to see test code, especially UI test code, managed as a completely separate entity in a version control system to the application code that it is testing. In this anti-pattern, tests are developed and maintained only in alignment to the latest application code. The danger here is that when you need to fix issues in previous releases you have no automation tests to cover a regression test. The test code base has moved on and can only be executed against code that is currently being developed.  

So whenever you make a release branch, make sure you branch your test code alongside it. 

It’s just common sense, versioning your test code alongside application code and running tests frequently allow regressions to be picked up quickly. 

Test Doubles

Sometimes your system under test is made up of multiple systems. Some of those systems may not be in your control, and others may be very difficult to operate in a non production environment. When this happens you can use a test double to mimic those particular parts of the system.

A test double is a generic term used to describe the various ways of mimicking a system and can be classified as follows

• Dummy objects - objects that passed around but never actually used. Usually they are just used to fill parameter lists.
• Fake objects - objects that actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
• Stubs - provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
• Spies - These are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
• Mocks - These are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting.

Test doubles can be used across the entire test life cycle, facilitating the delivery of code by solving tricky integration or environment problems. However, at some point it may be necessary to remove those doubles and carry out more realistic system integration test. You should always assess the risk of using test doubles and have at the back of your mind that these are not real systems or objects, and are just helping development move along.

For more information read:

Martin Fowler - Test Double   

xUnit Patterns - Test Double