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


How is Quilt Different

Stub methods not classes
Compiler signiﬁcantly reduces the amount of test code
that must be written to provide isolation


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 beneﬁts 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)


The Testing Barrier

To do Mock-Driven development you need to test ﬁrst


Should it be like this?


In quilt it’s as easy to test
after as it is to test ﬁrst

!"#$%&'($%


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
91,''#'%,2#%)2.60#5% +,&-"#'%,2#%'#0,2,&#5%
*$&.%,%:+,&-";% 78%:<#,/';%

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

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.ﬁll(posts);
return true;
}
return false;
}
}


!"#$!#%&$
'()*)+$
@Test
shouldBuildFoundationsWithLotsOfBricksAndSlowDryingCement(){
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:

@Test
shouldBuildFoundationsWithLotsOfBricksAndSlowDryingCement(){
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)))
}


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

shouldBuildFoundationsWithLotsOfBricksAndSlowDryi
ngCement(){
Seam:
cement.isSolid() returns false;
bricks.size returns 100;
AssertTrue:
new ConstructionSite().buildFoundation(..);

}}


No need to set up stub objects
ngCement(){
Seam:
AssertTrue:

}}


Stub Methods not Objects
ngCement(){
Seam:
AssertTrue:

}}


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
91,''#'%,2#%)2.60#5% +,&-"#'%,2#%'#0,2,&#5%
*$&.%,%:+,&-";% 78%:<#,/';%

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

Quilt Test: Running multiple
patches together

!"#$%&'()%&


Quilt: A new approach to
testing
Compiler stubs as much There is no need to
as possible create mock or stub
objects and inject them
Compiler forces the
into the test
isolation of the code
under test Developer needs to write
the absolute minimum
Methods are mocked not
amount of test code
objects
Can even test an existing
class


Test-Oriented Languages: Is it time for a new era?

More Related Content

Similar to Test-Oriented Languages: Is it time for a new era?

More from Ben Stopford

Test-Oriented Languages: Is it time for a new era?