test-oriented languages: is it time for a new era?

Test-Oriented Languages: is it time for a new era?Ben Stopford : The Royal Bank of Scotland

Friday, 25 March 2011

Mocking is fundamental part of Test Driven Development


But how much further can we go in current imperative languages?


What might we improve if we were not inhibited by current mainstream compilers?


What might we do with a blank slate?


Quilt


Stub methods not classes

Compiler significantly reduces the amount of test code that must be written to provide isolation

How is Quilt Different


Taking step back...


What are the motivations for mock driven development?


State based tests inevitably overlap

!"#$%&'($%

!"#$%&'($%


This makes it hard to diagnose the source of a break.

!"#$%&'($%

!"#$%&'($%


The solution is to use mock objects to provide substitute interactions that we can assert from our test !"#$%&'($%

!"#$%&'($%


Current Challenges


Coupling between test and source


“I've always been a old fashioned classic TDDer and thus far I don't see any reason to change. I don't see any compelling benefits for mockist TDD, and am concerned about the consequences of coupling tests to implementation.”


The JMock Era


Mock Interactions


All interactions must be explicitly coded in the test

!"#$%&'($%


The Mockito Era


Only mock interactions you care about

!"#$%&'($%


This reduces coupling between test and class


Quilt takes this concept further by only requiring methods to be stubbed not whole objects (but more on that later)


To do Mock-Driven development you need to test first

The Testing Barrier


Should it be like this?


In quilt it’s as easy to test after as it is to test first

!"#$%&'($%


What Makes Quilt Different?


The complier isolates testable units for you.

Where it needs your input it requires that you provide it.


So when you run a test the compiler will restrict the execution scope, say to a single class

!"#$%&'($%


If that class under test calls other classes the compiler will automatically isolate the interactions

!"#$%&'($%


If those interactions return state then the compiler requires that a active stub be declared in the test

!"#$%&'($%


So quilt creates seams around the testable unit isolating the functionality under test !"#$%&


Methods are Stubbed not Objects

!"#$%&'($%


Testing units can be one or many classes: a Patch

!"#$%&#'($)%&"*'%+,&-"%&"#%-./0*1#2%3*11%4.2-#%&"#%5#-1,2,(.$%.4%,%'&677#5%2#&62$%&80#%4.2%&"*'%/#&".5%

91,''#'%,2#%)2.60#5%*$&.%,%:+,&-";%

+,&-"#'%,2#%'#0,2,&#5%78%:<#,/';%


There is no need for dependency injection for the purpose of testing


The barrier for testing is lowered


Looking more closely


Compilation Ensures that Stubs are Required only if they Affect the Output of the Test.


class ConstructionSite{ Digger digger = new Digger(); Mixer mixer = new CementMixer(); Foreman foreman = new Foreman();

ConstructionSite(){}

ConstructionSite(Digger d, Mixer m, Foreman f){ digger = d; mixer = m; foreman = f; } boolean buildFoundation(Bricks bricks){ Cement cement = mixer.mix(); Foundation foundation = digger.dig(); BrickLayer layer = foreman.getLayer(); if(!cement.isSolid() && bricks.size()> 100){ Posts posts = layer.lay(bricks, cement); foundation.fill(posts); return true; } return false; }}

!"#$%&'(($


@TestshouldBuildFoundationsWithLotsOfBricksAndSlowDryingCement(){ Digger digger = mock(Digger.class); CementMixer mixer = mock(CementMixer.class); Foreman foreman = mock(Foreman.class); Cement cement = mock(Cement.class); BrickLayer layer = mock(BrickLayer.class); Foundation foundation = mock(Foundation.class);

when(mixer.mix()).thenReturn(cement); when(digger.dig()).thenReturn(foundation); when(cement.isSolid ()).thenReturn(Boolean.FALSE); when(foreman.getLayer()).thenReturn(layer); ConstructionSite site = new ConstructionSite(digger, mixer, foreman); assertTrue(site.buildFoundation(new Bricks(101)))}

!"#$!#%&$'()*)+$


In all this mock/stub setup only two parts are actually pertinent to the test:

@TestshouldBuildFoundationsWithLotsOfBricksAndSlowDryingCement(){ Digger digger = mock(Digger.class); CementMixer mixer = mock(CementMixer.class); Foreman foreman = mock(Foreman.class); Cement cement = mock(Cement.class); BrickLayer layer = mock(BrickLayer.class); Foundation foundation = mock(Foundation.class);

when(mixer.mix()).thenReturn(cement); when(digger.dig()).thenReturn(foundation); when(cement.isSolid ()).thenReturn(Boolean.FALSE); when(foreman.getLayer()).thenReturn(layer); ConstructionSite site = new ConstructionSite(digger, mixer, foreman); assertTrue(site.buildFoundation(new Bricks(101)))}


shouldBuildFoundationsWithLotsOfBricksAndSlowDryingCement(){

Seam: cement.isSolid() returns false; bricks.size returns 100;

AssertTrue: new ConstructionSite().buildFoundation(..);}}

!"#$!#%&$'()*+&,$


No need to set up stub objects





Stub Methods not Objects





Avoiding mock object chains

input.do().do().do() returns “foo”;


Static analysis lies at the heart of the Quilt compiler

The compiler tracks the state used in the class under test.

A bottom up analysis technique allows the compiler to exclude cross seam calls that cannot affect the test output.


The unit under test should be more than one class

!"#$%&#'($)%&"*'%+,&-"%&"#%-./0*1#2%3*11%4.2-#%&"#%5#-1,2,(.$%.4%,%'&677#5%2#&62$%&80#%4.2%&"*'%/#&".5%

91,''#'%,2#%)2.60#5%*$&.%,%:+,&-";%

+,&-"#'%,2#%'#0,2,&#5%78%:<#,/';%


Quilt Test: Running multiple patches together

!"#$%&'()%&


Quilt: A new approach to testing

Compiler stubs as much as possible

Compiler forces the isolation of the code under test

Methods are mocked not objects

There is no need to create mock or stub objects and inject them into the test

Developer needs to write the absolute minimum amount of test code

Can even test an existing class


test-oriented languages: is it time for a new era?

Documents

class cement cement

class foreman foreman

class foundation foundation

functionalityunder test

test thecompiler

couplingbetween test

test code

test andsourcefriday