Video from IAD 2010

December 9 2010

just updated personal page adding links to both slides and video for the presentation I had at the last Italian Agile Day 2010. enjoy!

Legacy pictures

July 18 2010

someone once stated that legacy code is simply “code that works” (I guess was Michael Feathers, but could not find any reference online). Feathers himself proposed characterization tests as a vise to put legacy code into, before starting doing any change.

this week had the pleasure to add support to our current application for customer’s internal search engine indexing, something already developed by some colleagues of mine, for a similar web application. so, I spent some time reading product documentation and reviewing existing code, which was clearly composed of custom domain logic and generic integration logic with given product. I also played a bit with code, in a sandbox, to understand how pieces could be splitted.

then, I reverted every change, and started writing an initial characterization test.

main application entry point was a “workflow” process, expected to be executed by the application container when a few events had occurred. visible behaviour consisted of text files, with specific content, stored via FTP. so, I first “reproduced” current behaviour starting a local FTP server (bundled with my MacBook, and available from System Preferences). after having seen text files written, I could write an automatic test (well, automatic but not yet reproducible on every workstation).

@Before
public void setUp() throws Exception {
  ...

  ftpFolder = createTmpFolderAt(FTP_HOME_FOLDER);

  properties.put("ftp.url", FTP_HOST);
  properties.put("ftp.port", FTP_PORT);
  properties.put("ftp.user", FTP_USER);
  properties.put("ftp.password", FTP_PASSWORD);
  properties.put("ftp.directory", ftpFolder.getName());
  properties.put("base.url", "http://www.mysite.com");
  
  Hashtable<String, String> properties = new Hashtable<String, String>();
  activate(facade, new InMemoryComponentContext(properties));
}

@Test
public void shouldNotifyNewsCreation() throws Exception {
  String lavoro = "/its/a/news/lavoro";
  ...
  
  String[] arguments = new String[] { "creazione" };
  process.execute(workItem, workflowSession, arguments);

  String expectedContent = "VdkVgwKey: http://www.mysite.com/its/a/news/lavoro.xml\n<<EOD>>";
  assertEquals(expectedContent, contentAt(ftpResource("/lavoro.bif")));
}

helper methods simply read resource content, stored at a given URL:

private String ftpResource(String resourcePath) {
  return
    "ftp://" + FTP_USER + ":" + FTP_PASSWORD +
    "@" + FTP_HOST + ":" + FTP_PORT + "/" + 
    ftpFolder.getName() + resourcePath;
}

private String contentAt(String urlAsString) throws Exception {
  return ContentUtils.readUrl(new URL(urlAsString));
}

then, was the turn for turning my local FTP server off, and using one for testing purpose. I have to admit, I tought it would have been easier, I’ve done this many times for HTTP, mail and JMS servers, but getting an FTP server started and stopped by a JUnit test turned to be painful! I played with MockFtpServer (hung waiting FTP data on port 0, no way to set any other port), then Apache FtpServer (had no luck with user grants on filesystem) and HermesFTP (gosh! it requires Spring for running!).

then found a lightweight and simple Java FTP server: AXL FTP Server (details for adding a Maven dependency are available here). its entry point it’s a Main method: i just managed to start a server thread on test setup and stop it on test tear-down (actually, on suite setup and tear-down).

// see src/test/resources/ftp/ftp.cfg
private static final String FTP_HOST = "localhost";
private static final String FTP_PORT = "2121";
private static final String FTP_USER = "foo";
private static final String FTP_PASSWORD = "bar";
private static final String FTP_HOME_FOLDER = "/tmp";

private static Thread serverThread; 
...

@BeforeClass
public static void startServer() throws Exception {
  serverThread = new Thread(new Runnable() {
    public void run() {
      ftpd.main(new String[] { "src/test/resources/ftp" });
    }
  });

  serverThread.start();
}

@AfterClass
public static void stopServer() {
  if (serverThread != null) {
    serverThread.stop();
  }
}

it was a matter of a few configuration files, which I put under Maven test resources folder (ftp.cfg for server config, and dir.cfg for users and filesystem grants).

this gave me confidence, really, adding a few more test cases. I could then start restructuring and refactoring code: extracting a brand new project, then removing duplicated logic, extracting classes and interfaces with clear names. in this process, as long as I was changing code, my understanding of the whole notification process improved.

in the end, I could easily move FTP integration test to the new project test suite, while unit-testing original code for workflow process with test-doubles (in-memory fake objects and mock objects). more unit tests were added, along the way, also.

well, it was really not legacy code, not yet! it was lack of automatic tests. this gave me the opportunity to apply Feathers’s process: take a picture of current behaviour, before starting refactoring code.

Amsterdamned

November 6 2009

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!

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

February 17 2009

.. 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!

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.

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!