On "Testing and Refactoring Legacy Code"

I finished watching Sandro Mancuso's "Testing and Refactoring Legacy Code" excellent coding kata on InfoQ and I saw there a couple of practices which I can hardly wait to use in real (legacy) projects.

Although that the overall movie quality is not so good, I had no problem understanding the code and the incremental refactorings.

What I liked the most were the practical pieces of advice that are meant to transform developers in real software craftsmen.

On my TODO list:

• split editor when writing (or reviewing) test code
• add tests from shortest to deepest branch
• refactor from deepest to shortest branch
• use coverage tools when adding tests
• introduce builders quickly
• use MockitoJunitRunner 

Agile comunity growing in Timisoara!

Last week I had my first Meetup on the Timisoara Agile Software Meetup Group!

Although I was at first reluctant to go since I knew almost nobody from the Meetup's members, surprise - surprise, my general impression was surprisingly good!

Attended a well prepared, well structured and very interactive Unit Testing presentation together with experienced/un-experienced agile practitioners and wannabes. It felt good to see so many people there - all in their free time, the majority of them drove there simply by passion.

Another plus for the organizers were the cookies! We had free coffee, drink and cookies. Sharing food always creates magic.

What I missed was only "the beer after": some time dedicated to free and direct conversations, the real meet. A lot of persons approved - next time we'll have a beer after, so if you come, be prepared for half a day of agile discussions and beers!

A Pattern Story

As mentioned in the previous post, the pattern story:

Being an adept of automated functional testing, knowing the complexity of our untested GUI classes, I knew we had to do something about it until it's too late. [The Right Time].

Knowing other attempts and their failures to introduce automated functional tests in my team [Test the waters], I did some Google research and quickly discovered FEST.

It's simplicity and it's java syntax attracted me, I knew it my have a chance of adoption in my current group [The Right Time]. I also was clearly aware about the benefits that automated GUI tests will provide us [Evangelist]

I started using them on my PC [Test the Waters, Just Do It] and spread the news to my friend co-workers [Innovator, Early Adopter].

We had discussions about the idea and the small progresses I had during lunch time: the time when people can talk! [Brown Bag]. Invited them to check for themselves [Trial Run].

After first successes [Small Successes], I began to spread the news on each occasion I had: invited fellow programmers to see the tests running and to assess their value, corridor discussions about status, etc [Stay In Touch].

I had the opportunity to discuss also with my boss about the possible opportunity [Guru on Your Side, Whisper in General's ear]

Our team had a dedicated day for developers only: Lock-down session.[The Right Time ]. In that specific day I proposed to have a look as a team to the FEST framework and the tests that can be done with it.

Decided that developers that have some experience with FEST to present it's features to developers who hadn't played with the tool: [Involve Everyone, Hometown Story, Trial Run] Simple demo's, no handy features! [Just Enough]

The concept was approved! We could commit our tests on SVN!

Started to build upon FEST a mini-framework better suited to our project's needs[Small Steps], let everyone know what I was doing [Involve Everyone]. Asked for help for SVN source organization and for the mini-framework design. [Ask For Help].

Ran the FEST test suite before each delivery of my module(the test suite was growing), invited everyone to see how I "do nothing" to test the release, and let everyone understand the amount of confidence a good suite of functional(GUI Tests) can provide[Smell Of Success, Personal Touch].

Similar test suites began to raise for other modules in my team and for other modules in neighbor teams [Early Majority]. Traditional skeptics became FEST fans and began to heavily contribute to the "GUI testing" phenomena. [Bridge-Builder].

The idea had more success than I expected: we have a colleague that became FEST Contributor, a colleague wanted to use FEST as an aid in his school presentations, started to use TDD, etc.

What I would like to do now is to thank again everyone who invested time and patience in this idea. Without their help, nothing would have been done: Thanks a lot guys, you really helped! FEST is now yours! ;)[Just Say Thanks].

Q.E.D

PS: If I only new earlier what I have learned from the book... :)

TDD is vague

I was asked recently about TDD:

What is it exactly? What's the difference between it and Test First Programming?

The questions were raised by one of my colleagues in a Test related activity we had. (Simple curiosity about a handy acronym heard somewhere some time ago and if applicable to what we were doing)

My quick answer: "Test Driven Development is not only about writing your test first! It implies you also see the system as a tester/user. In TDD you ask yourself questions like: What can go wrong? What other scenarios must be considered? Guidance from a preventive QA team would be welcomed in this process... "

Context : we were developing(peering) a new feature - new GUI and related functionality in a TDD manner, writing quickly the functional test (called by us "GUI test") before, and trying to keep the green bar afterward.

After some reflection I realized that TDD is a vague acronym. Why? Because "Development" is also vague.

Development examples :

• explore a simple idea: It might be possible to create this new method that will save us from this amount of code duplication.
• explore a new technology, use it in the application: Can we use hibernate? Yes. We need to use these annotations. Data is persisted.
• design a number of classes with complex behavior: We have performance related problems - we need to cache previously computed results. We must be able to invalidate the cache.
  
• design a number of classes with complex structure: For the given primary inputs, we must be able to compute and save intermediate results.
• build business structure: Make this "Foo" editable, you did the same for "Bar"
  
• build business behavior: We have to create these Business rules.

So TDD could mean:

• Test Driven Exploring (driven by learning oriented tests)
  
• Test Driven Design (driven by design oriented tests)
  
• Test Driven Structure Implementation (driven by GUI oriented tests)
• Test Driven Behavior Implementation (driven by acceptance criteria oriented tests) - thank god we already have a name for this : BDD
• ...

So, answering TDD is not easy, it implies Test First, it implies small steps, various external preoccupations on a case by case basis: what may break my design, what other GUI interactions may work wrong, when can we say acceptance criteria passed, ..

It's been a while since I wrote this post. Reached a very nice post about another TDD meaning:

• Test Driven Refactoring (driven by refactoring oriented tests)

Reached another nice post regarding TDD & Test First: TDD does not mean Test First. "TDD does lead to better code - test first does not." Really enjoyed the formulation!