Amsterdamned

i’m back.

for the last two weeks, i’ve been staying in the lovely city of Amsterdam, working for a customer of my dutch colleagues. challenging, amusing, funny and resource-consuming, here’s a brief recap of my last 15 days.

first of all, thanks from the deep of my heart to Maurizio “daje forte” Mao Pillitu, for hosting me in his nice and comfortable home, just outside the city town. he’s been very kind and friendly, i hope i had in some way paid back with my italian-style cousine.

so, i’ve been working for Hippo, a young and energetic open-source company born around their CMS product: it’s a nice building down-town, just 15 walking minutes far from Dam square (yep, i loved walking through the city lanes after a full day of working). guys at Hippo are friendly and passionate, devoted to open-source; they also organize forge-fridays, sort of coding dojos with the focus on releasing working plugins (for Hippo CMS, of course) at the end of the afternoon.

Hippo CMS is having a lot of popularity among public institutions in the Netherlands, something my dutch colleagues have been working on hard also. but even if Hippo 7 is getting popular, there are still a lot of projects done with the older product version, Hippo 6. And that’s were my story begins.

i’ve been working for the municipality of Schijndel, a little dutch town, helping its IT management improve and automate meeting’s agenda and reports publishing. yeah, you heard it right: they record and publish (with a little delay, of course) audio and text content for every council’s meeting. being an italian citizen, all that transparency and devotion sounds strange, but is really laudable.

the first challenge i faced was, of course, translating all documentations from dutch to english, from analysis PDF to past emails with customer. i didn’t had everything clear at first, but thanks to double-checking with dutch colleagues i finally got it. (anyway, it’s funny almost every translation from dutch gets verb in the very last part of sentences. it really reminded my latin classes, while at college).

then i finally entered the dark tunnel: technology viscosity and indecent web of dependencies, also known as Maven 1. gosh, i really had to work hard to have a successful build on top of Java 1.4, Axis2 and Cocoon 2.1, which turned out to be classpath monkey-patching, using ant tasks, jelly scripts and maven postGoals. damn!

add lack of support from webservice’s developers and consultants, and the soup is ready to be served! in fact, i just had a working test environment (i mean, representative of customer’s one, with valid data) almost 3 days before the project scheduled end. that’s awesome, isn’t it? how did the hell i managed to get the work done?

applying what i later called the “abstract and adapt” strategy: understand the domain, abstract from implementation details, then adapt code when things get clearer. well, that’s the hexagonal architecture (but, you know, we like coining sexy names). so, i spent the whole first week coding the application logic decoupled from real system behaviour, which in fact was unknown. Agenda and its Repository, Content and Storage, Indexer and Importer, these are all roles i’ve been writing, test-driven, from day one. that’s not easy, and of course it’s risky; but it was the best i could do.

reading webservice specifications and WSDL, i could also guess how that slimmy layer should behave, but i really got it wrong at first! then, i had an ah-ah moment during the first weekend, and changed the webservice adapter in order reflect my new thoughts, without the need to modify domain logic so much (in fact, i also improved my domain knowledge). i changed unit tests, and added sort of spikes: tests with no assertions, just logging actual parsed responses, so that i could “see” with my eyes current webservice behaviour, at each test run.

and i was right! i clearly remember how shocking was reading in the console log some parsed data, when they finally were set up on test environment! you know, i was going for lunch, i ran all tests one more time, before locking down workstation, and i saw that: “parsed 6 agenda”, following by a so-nice full toString(). that was awesome, really: my tests told me setup was done before receiving a confirmation email by consultants, 30 minutes later!

than, i had my journey to Schijndel, to discuss deployment and testing on customer’s network. trip took 2 hours, i also had a 30 minutes stop in ’s-Hertogenbosch which i spent walking down-town, among nice gothic buildings and golden dragons.

it’s shocking how efficient dutch national transports website is, with its door-to-door journey planner, really. well, it’s a shame it’s not updated with temporarily moved bus stops, which could have saved me one hour in the late evening!

anyway, that’s it, a recap of techy stuff mixed with journey reports. thanks to the whole dutch office for the opportunity and drinks, looking forward to next works together!

Fakes aren’t stubs

yep, title resembles Fowler’s article on interaction vs. state based testing. that was one of my first readings when i approached TDD, and soon i fell in love with mock objects. things change, of course, but that’s another story…

very close to my heart, there are “test doubles”, see Meszaros work on this. last xMas i also gave a presentation on that (a webinar to my colleagues in Amsterdam and Rome), and i tried to make clearer how and when to use doubles in tests. but i still missed one point.

testing in isolation. well, i want to test a bunch of code without depending on other parts of the application. in OO systems, code is moduled into classes. using Responsibility-Driven Desing terminology, you need to isolate tested class from responsibilities it collaborates with, which usually form one or more role.

while doing TDD, isolation isn’t a goal, but quite a medium: to add the smallest behaviour possible, you need to isolate from whatever isn’t stricly related to the task at hand. indeed, you often discover collaborations while wrinting an automatic test: roles emerge.

mock objects help on that: as the mockist fathers say, “mock roles, not objects”. hand-written mocks or dynamic mock object libraries are the way to go, choose one. these days, i’m with the former by default, and for using tools on more complex scenarios.

isolation can also be reached without the need to programmatically set behaviour (which is the essence of mock objects), relying on pre-set stubs, which usually behave in a default way (do nothing on void methods, return some simple, fixed values otherwise). stubs are really useful to simply ignore collaborations. if you want to, stubs can also be programmed, overriding default values.

then, it comes the time when you need to test a bunch of classes: say, integration tests which touch system boundaries, or acceptance tests focusing on domain, which don’t want to go live. of course, they’re coarse-grainer than unit tests. in these scenarios, you simply can’t mock-out collaborations. even more, you probably don’t want to.

to verify something has worked as expected, some real beaviour is needed: say, storing data on file instead of a RDBMS, reading input from a local file-system instead of an online storage, and the like. one of the best examples i’ve recently read is Pryce’s work on TDD of Asynchronous Systems, where he effectively substitute a few pieces of an application with fake ones.

in other words, fake objects are complete and consistent implementation of a given role (i.e. an interface). you just won’t probably use them into production code, even if they would do their job. most common example is an in-memory repository: store, update and retrieve objects in a coherent way. Fowler’s definition is:

“fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).”

sure, “fake” is not a great name! to get fakes less depressed and let them gain self-esteem, here’s my campaign: consider them first-class citizens, and please, stop calling them fake when you’re really just looking for a simpler, poorer, more stupid stub!

Working software

.. over comprehensive documentation.

yes, that’s one of the very clear sentences in the Agile Manifesto. but there’s more.

last tuesday i attended a presentation on Agile and XP Gabriele gave at the local Linux User Group in Cremona. the session was very good, people interested, a lot of discussion, me too, bringing my last two years experience. but please, always trust a geek saying “go on as long as you like, we can stay here ’till late night”: he’s serious!

Gabriele is a great speaker, i had never seen any of his presentations before. amazingly, in three hours and half, he just scratched the surface of common topics such as testing and refactoring, instead focusing on planning and (re)estimating.

i learned a lot too. mainly, my attention was caught by this sentence: “our main goal is not to develope software satisfying business requirements, our goal is to develope software our customer can gather value from”. in my view, this is the essence of any Agile development process, and, in fact, is also stated as the first principle in the manifesto too: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” (emphasis mine).

i spent a lot of time studying, learning, using and adjusting user stories acceptance tools, and helping developers understand how much “do the thing right” and “do the right thing” are different. but, even then, having all the acceptance criteria clear stated, is our job to verify them? do our customer pay us to do whatever he ask to?

definitively not. we get money to deliver software someone can make money with, or do something less costly with. or maybe, software doing something not feasible doing by hand. choose one. anyway, our job is to let our customer achieve his goals using our product.

for me, that’s really a context shift, and a daily challenge. i’m always focused on the internals of a system’s design, it’s architecture, how pieces work together. i live in an iperuranio where objects talk each other; where ideas born, live and evolve, and finally get real as working software. i’ve never paid much attention to what software is used for, i’ve always considered it a detail.

what a mistake!

from now on, contract i’ve signed as a developer is:

i’m allowed to imagine, design and construct the best (and simplest) system i can think of, as long as my goal is to deliver value to the customer.

working software over working acceptance tests!

Online italian Alt.NET conference video

thanks to Simone, last italian Alt.NET conference’s video are online.

so, are you tired? nothing on TV? girlfriend/boyfriend sick? maybe you could spend quite an hour with me talking (in italian) about acceptance tests and FitNesse.

Customer TDD and FitNesse at italian Alt.NET conference

as already posted a few days ago, next saturday i’ll be giving a presentation at the italian Alt.NET conference, hosted in Milan by the company i work for, Sourcesense. basically, it’s the same Tommaso and me gave at ESSAP last summer, but i’ve ported the basic examples in C#, packaged them all in a NAnt build script runnable both on Microsoft .NET and Mono. i’ve developed the code on a MacOS with Mono 2.0 and tested with a MS .NET on windows too.

no slides nor mind map this time, i’ll be using FitNesse pages themselves to show how FitNesse works. the code is here.

hope the README file is enough to start working with the examples. on MacOS i had troubles with the boundled NAnt that comes with Mono, so i had to manually add this to my .profile file, as described here:

export PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Versions/Current/lib/pkgconfig

thanx to all the Alt.NET guys for the opportunity, and to Luca first, who was my proxy to the community.

happy customer-testing!

Test tastes

it’s been since a while our team decided to discuss different approaches we’re using on testing – it’s one of the actions voted on last team retrospective. we’re growig as a team, (great) new team mates recently joined, and everyone it bringing more experience and ideas. and testing is one of the most interesting item everyone has in his own agile “toolbox”.

yesterday Matteo started discussing, posting his ideas on acceptance and integration tests. he has done a great work, trying to explain his point of view while showing other’s, such as Shore’s. and me, i put a note on my “to-blog list” long ago, so it’s time to talk a little about.

tests are artifacts, testing is an activity. the funny thing is that you can use tests to actually do something completely different from testing. it’s something as clear as understand which role the T plays in Test-Driven Development: use tests to drive your development. time for some examples.

1. unit-tests are for designing. you write a unit test before coding, you use a red bar to clarify ideas on how thing should go, and you code until the bar becomes green. then, you use a green bar to safely check you’re not changing behaviours, while refactoring – improving the design.

2. integration-tests are for testing. ok, that’s interesting. unit-level design is great, but it’s not the whole story. we want to be sure assumptions we did really stands, both inter-connecting with external systems and putting “our” pieces together. it’s really hugged with architecture, so that modular architectures better help testing on different scales (such as one-side at a time, when using an hexagonal architecture).

3. acceptance tests are for understading the domain. in other words, requirements: business rules, constraints and flows. ATs are great to explain generic rules using examples. being automatic, they’re also sort of regression tests. again, modular architectures let ATs be independent, self-contained within the domain layer.

maybe in a past life i was a tester, because i still miss something. i find myself having need of one more test, just one, running from UI deep through the persistence. Matteo calls it an end-to-end test, Miško use the term scenario test, for me it’s just another integration test (ok, they’re twins separated at birth).

call it as you like it. by the way, having a look in our last codebases, i see we had few ways of testing the application when connecting to a subset of external subsystems:

• an acceptance test, when rules were focused on presentation
• an integration test for the topmost side of the application, such as the Controller
• an integration test through HTTP, for web applications

that’s how it goes. i’ll really appreciate some feedback on this. so, how do your tests taste?

Be polite, share your transaction

it’s about six months since i’m using the Spring framework in our current codebase (i played with the .NET version in the past), and even if my team don’t usually like to use “imposed” frameworks, or don’t like to use a framework for doing everything, thanks to Spring i’ve been able to do something extremely impressive: share a transaction between an HTTP integration test and the webapp under test. here it comes.

there are a couple of patterns when testing data access code, in order to get rid of all the test data setup. in the worst case, you can manually delete all inserted data, if you can distinguish them from the existing data (basically, ids are created by the test, or there’s a criteria such as “latest” data – some versioning field is required). better scenario, you open a transaction in the test setup and perform a rollback in the teardown. that’s nice, you only need to share the transaction beetween the test and the system under test. with or without Spring, it’s a common strategy, well documented in literature and for specific techologies.

well, everything goes fine, untill you reach the system level, and you still want to perform a leave-data-as-you-find integration test. that’s what i was trying to do a few weeks ago, in our current project. we decided on having the simplest end-to-end test, from presentation deep through data tier (compiled SQL stored procedures on the database). we already had a great test stack for that, a combinantion of

• Winstone, for deploying inside an in-memory servlet container the whole webapp
• HttpUnit and HtmlUnit, for connecting to the webapp
• Spring datasource injection, using the classpath as a link seam to switch configuration to a development database

in other words, we could be able of running the webapp connecting to our in-house database, and test the resulting HTML content, without the need of any deploy outside the test execution: all in memory, baby! that’s fine, at least untill you need to test some “actions”, modifying the underlying data. that is the time when you need something more.

the simplest solution was to “detect” some id for the inserted data, and hopefully we had! we randomly generated a description and used it inside a DELETE SQL statement in the teardown. but soon things got worse, and this strategy was no more feasible. so i thought “well, i can share a connection beetween the test and the webapp, can’t i?”. well, it’s not so easy!.

the main point is that while running a test with a in-memory servlet container, the webapp has its own WebApplicationContext, and there’s no way to get it from the test: even if you refer to the same xml file, the application contexts are two separate instances, connecting to the same database, but through different connections.

remember what i said before, today story is about how to share a transaction between test-code and webapp: hold on, we’re getting there! main actors are two nice features of Spring:

• shared application context, have both webapp’s WebApplicationContext and test ApplicationContext refer to a parent context
• TransactionAwareDataSourceProxy, embed inside a transaction an existing datasource

shared application context is usually used inside EAR modules. by the way, this is all i had to change in the configuration:

• in web.xml add a value for param parentContextKey, such as shared-resources-context
• create a beanRefContext.xml file, with a ClassPathXmlApplicationContext on classpath:datasources*.xml
• remove datasource definition from applicationContext.xml

we can now refer to the shared (parent) application context this way:

@Before
public void setUp() {
    BeanFactoryLocator singletonFactoryLocator = ContextSingletonBeanFactoryLocator.getInstance("beanRefContext.xml");
    beanFactory = singletonFactoryLocator.useBeanFactory("shared-resources-context").getFactory();
    dataSource = (DataSource) beanFactory.getBean("dataSource");
}

almost done. next thing is to assure webapp and test access the same datasource, and that’s the main business of TransactionAwareDataSourceProxy, used in combination with a SingleConnectionDataSource (both from Spring).

for the lifecycle of a test, everyone is accessing to the same connection, which now is transaction-aware. finally, we can use a transaction manager to start and rollback a transaction at test boundaries.

quite a long story, hope you enjoyed. i gzipped a simple webapp here, please have a look yourself: it’s an Eclipse project with code, test, sql script and all required libs, but it still lacks a README file (i’m quite tired and i want to post, i’ll add notes later).

i really hope this can be useful to your project, feel free to use it, and send me feedback.

Not sure? Write a test

today i was pair programming with a developer (in my no-more-so-extended mentoring activity). i joined her desk while she was fighting with a complex test (reflection stuff) on a huge object mapper (about 200 fields). i already told her some days ago that, maybe, there could be a way to split it.. nevemind, today the issue was with the test.

first thing i suggested was trying to find which part of the test was wrong, so we started “refactoring” the test moving one piece in a separate helper class and test it in isolation. [i said "refactoring" because there was no green bar when we started. it was like working with legacy code, which you wuold like to refactor, having no test at all.]

i know, maybe it sounds strange to test the test (as the Latin said, “Quis custodiet ipsos custodes?”), but i found many times it’s a good way to get feedback on what’s going on, expecially when you’re “developing” a base test class, instead of extracting it from existing test code.

so, we had a green bar on a simpler scenario: mapping a custom object (a two fields DummyObject class written just beside the test) with the super-magic-reflectionist helper class. then we put some complex field into the dummy and added assertions to the test. bingo! a red bar on the screen, telling us that, probably, we found a way to reproduce in a smaller scenario what was the failing cause.

dilemma: was the tested code bad or the test itself poorly written? i had no idea (i was very very tired, but pleased of someone asking for my help), neither she. when i’m completely lost, i need some feedback, in order to say “ok, this piece works, that doesn’t”. so i asked my mate “are the test data correct? do you think this Map contains a value for X?”. as she said “obviously no!”, i exclaimed “well, let’s write a test!”

what a surprise when we had a failure on assertFalse(mappedValue.containsKey(".."))!

it was now clear: the test was wrong. what we then did is not so interesting (basically, write a simpler and correct test and have it pass, then move back to the original scenario). the focus in this story is on using the tests as a way to gather feedback, whatever you’re doing: coding, testing or spiking.

many developers don’t see the value in testing as a feedback tool. they prefer to code and debug. in my opinion, debug is a powerful but exhausting techinque, that’s why i use it only in emergencies – when there’s no other way.

my mate for today, very smart, she sometimes make fun of me because everytime she ask me for help, i always ask her for any running tests, otherwise i start writing one. anyway, i hope sooner or later she’ll start writing test-first herself. get test-infected.

What’s your avatar?

there’s a nice paper by Naresh Jain, actually a draft, called Avatars of TDD. basically, Jain recap all the different approaches he found while pairing with a lot of people doing TDD. he categorizes some approaches based on the use of business-facing or programmer-facing tests, acceptance or unit test tools with or without mocking framework, static or dynamic languages and, finally, the paradigm: object-oriented or functional.

and what about you? how do you start working on a story? ok, while you’re thinking, i’m going to tell you something about me.

i first learned TDD while working on my master thesis, and it was also the time i fell in love with mock objects. that’s why i decided to write a mocking tool as my thesis work (the idea was cool, describing TDD while developing a TDD-enabler tool). i also explored FIT/FitNesse for upfront defining acceptance criteria for a given story. that time, i used to start from a FitNesse page and then write unit tests for the most “external” class, mocking collaborators. then, i would have shifted on testing collaborators themselves, and so on. i call this top-down interface-discovery (as first described in the Mock Roles, Not Objects paper).

time has passed, i’ve paired with a lot of developers, and grabbed a lot from their style of TDDing. while still aware of the benefits of mocking frameworks, i now prefer to use hand-written fake (such as InMemoryDao instead of a dynamic mock generated at runtime by a tool), start from the “inner” functionalities, and climb-up till the top, in a bottom-up fashion. my design tools are a quick todo list of main responsibilities, sometimes a rough UML interaction diagram, and a sketch for acceptance criteria drawn on paper. i now focus less on interaction-based tests and more on state-based tests: even for interaction, i end up writing assertions on handWrittenFake.currentState() or spyCollaborator.timesInvoked().

ok, time’s up. hope you enjoyed the story. now it’s your turn: what’s your avatar?

Guard test, my brand new friend

ever had to work with external subsystems? even worse, had to write an automated test which has to communicate with those subsystems? it can be a nightmare, and as soon as you don’t expect, you find yourself in a mess trying to update the test suite with new test data, in order to have the test pass.

assuming the contract it’s clear, the simplest solution is to write a unit test on our code using a test double implementation of the system (where “test double” stands for fake, stub or mock – choose one). that’s fine, and best of all, you can reuse that double inside an acceptance test too. you decide to focus on the business rule and isolate from real subsystems. [ Matteo wrote a great essay on this, telling a story from one of our current customers. ]

yep, but i’m still waiting for a green bar on real subsystem calls! sometimes you really need an automated test glueing together application logic and external infrastructure, such as a DataAccessObject (aka gateway or broker) to a stored-procedure written and maintained by another team. you are in charge of passing correct values to the dao, depending on some business scenarios, so you really wants to know when (not if) something stops working: database not tuned, high data volumes, network troubles, and so on.

wait, you can use an integration test, don’t you? that’s true: but, insted of testing our code calling external system, why don’t we test that system itself? we can use real data, the same we’re going to use inside an acceptance test, on a real scenario. this is something we’re using since a while in our team, and it seems it’s working. we call these guard tests: when an acceptance test starts failing, there’s always another test broken, a guard test, telling us “hey, relax! it’s not so bad”.

now, it’s time for an example. the first time we introduced a guard test was for a story like “user selects a market sector. when news on companies from that sector arrive, the user is notified”. we had to integrate with an existing dao for sector -> companies association. so, we found ourselves writing a characterization test for that dao, something like “given sector General-Financial, we expect to find at least two companies: company X and company Y”. this is our guard test. having clear how to use the dao, we unit tested the code in our application using it – an adapter. finally, we wrote an acceptance test for the whole story, using real data: we simulated a news for company X and added and assertion on user being notified.

to recap, we had:

• a unit test for how our adapter uses the dao, with a test double
• an integration test for the dao itself – the guard test
• an acceptance test using the real dao

everything worked fine, at least for the first few weeks. then, as expected, data migration happened, and the build was broken. [ yes, it's really strange to see market sectors composition change! we finally found out that earlier database data were fake - manually added by developers. ]

the happy part of the story is that we had both acceptance and guard test failing: good news, it’s just a matter of data! we spent a bit investigating the database content (while waiting for an automatically-deployed-development-database with dbdeploy) and fixing both tests.

so, what’s the morale? it goes like this: try to understand business rules with acceptance tests isolated from infrastructure details. good. anyway, if you need to write AT using real systems, add a guard test too: two red bars are better than one!