A very true statement.  But I don’t have to be happy about it.  Nope.  I’m dragging this Sunday out as long as I possibly can and I ain’t doing jack crap.  Except going to the store to get the dogs more food.  But that’s it.  After that, it’s back to the couch and surfing the TV for holiday specials.

Today marks the end of my stay-cation.  My glorious six-day-paid-time-off vacation spent at home.  No more of this.  Boo.

No more afternoon naps curled up with the BDD. 

No more lunch breaks in front of the TV. 

No more playing on the internet because I want to. 

No more pecan pie or pumpkin cake.

No more taking random pictures of the doggin while she sleeps.

I’m actually going to miss that last one a lot.  I could do this at night but there just isn’t enough light to satisfy me.  I’ve come to realize my doggins do nothing but sleep during the day.  I like it best when I get to catch some zzz with them. 

Back to the grind tomorrow.  And it will be the grind because it is a super-duper busy day and I’m not looking forward to it.  That’s the bad thing about taking off work – you end up giving yourself more work in the end.  But at least PodMate’s smiling face will be there.  Well… let’s hope she’s still smiling.  She might be cursing my name by now.  :)

In part 1 and part 2 we covered setting up MSpec, writing our specifications and then implementing one of those specifications.

So far we’ve covered very simple tests for code which has no external dependencies and does very little. Now we’ll turn our attention to those tests which (on the face of it) are more complicated and cover code which relies on data access, email services etc.

Lets tackle the the “when asked for products matching search term” specification.

Establishing Context

As before, we’ll start by establishing the context for this test, and to cut down on duplication, I’ve moved the basic context setup to its own class.

Now we can make all of the Product Controller tests inherit this class.

To implement the specification “should retrieve a list of products…” we want to simply check that the controller asks for a list of products from wherever we’re hoping to get our data from.

In the spirit of writing tests first we haven’t got any kind of data access layer yet so now we decide we need a Product Repository.

Rhino AutoMocker

To help test our repository we can introduce Rhino AutoMocker to the equation. Rhino AutoMocker is included as part of an AutoMocking library distributed with StructureMap.

To use it in your project, simply download StructureMap and reference StructureMap.AutoMocking and Rhino.Mocks in your project.

We need to wire up the automocker so we can use it in our tests. To that end we’ll change our base class.

So what’s going on here?

1. We’ve introduced an instance of the AutoMocker for our Product Controller.
2. To make life easier we’ve introduced a field which references the AutoMocker’s “class under test” (in this case our Product Controller).
3. We’ve asked AutoMocker for an instance of IProductRepository and also referenced this as a handy field (which we can use in our tests).

Now we can turn our attention back to the test.

Setting Expectations

1. We call a new overloaded version of our controller’s Search method (which accepts a string search term).
2. Then we perform a simple check to assert that the FindProducts method was called on IProductRepository.

Finally, we want to check what gets sent back to the view. For now we’ll simply check the name of the view being returned (and that the result is a view).

As I’ve gone along here I’ve implemented just enough to have the test compile.

IProductRepository

ProductController

At this point we want to make the test pass so let’s do that.

Now our MSpec tests will pass.

When we run the tests, AutoMocker will generate a mocked version of our IProductRepository which our test uses to assert which methods were called. By letting AutoMocker generate our mocks we cut down on a lot of boilerplate code but don’t really loose anything in terms of flexibility and control (we can manually add mocks if we don’t want AutoMocker handling them for us).

Stubs

Now lets say we want to check that the list of products retrieved from the repository is actually sent back with the view.

For this, we can set up the automocked IProductRepository to return a specific list of products which we can then check are sent back to the user.

Lets start by telling automocker to stub the Search method and return a new list of products.

1. We’ve added an Establish Context to our test (this will be used in conjunction with the one in our base class)
2. We’ve said that when the FindProducts method is called with the parameter “test” then a new generic list of Product will be returned

Now we’ll change the implementation of the spec to check that this same list of products is returned with the view. Whilst we’re at it we’ll move the test for the view’s name into it’s own specification.

Putting it all together

So finally, our completed test implementation now looks like this…

Hopefully these posts have demonstrated how well MSpec and Rhino AutoMocker can work together. The key is that the tests are easy to maintain and clearly state the criteria by which to judge whether the code under test is valid.

These criteria are stated as human understandable specifications which can be agreed with your users before writing any code. RhinoAutoMocker makes mocking and stubbing very straightforward and helps you to defer making decisions until the last responsible moment.

You will find the source code for this sample project on GitHub.

Nana-nana-nana-nana-nana-nana-nana-nana… BAT DOG!

We had a little adventure yesterday.  Chevy & Chase, my beloved doggins, got out of the backyard.  We have a gate on our deck that sticks and you see, we don’t exactly latch it.  The dogs have managed to get it open when someone comes to visit but never have just pushed it open for the helluva it.  Guess what?

Everyone got home safe and sound.  Chase ventured much further, taking in the sights on her little walk.  Chevy only made it to the corner – the kids in the yard were a major distraction and she just couldn’t resist.  She also could resist Rev when he approached her (we say that she calls Rev her boyfriend).  I’m just glad my BDD didn’t decide to chase a car because she’d probably be a BDDD: Big Dead Deaf Dog. 

The escape artists were pooped after the whole shenanigan was over.  After lapping up 3 gallons of water, they settled down.  Chevy, the doggin that most likely opened the gate [because she has bigger muscles than Chase], curled up for a  nap.  And when this happens, I think photoshoot!! and stick the camera in her face.

Now imagine Chevy can talk.  I do this quite frequently.  We have conversations about life as we know it.  And she has a really deep voice because she’s a big dog.  This is what she was saying while I was taking her picture.

Man, it’s nice outside.  I should totally go to the door and see if food lady will open it.  Those midgets were fun.  They might still be there.

Ah man, my head got too heavy again.  I hate it when that happens.

I better stay right here.  So comfy.  And food lady’s got that shiny thing in my face again.  If I lay real still maybe she’ll go away.

Or…I’ll… maul… fa…

*stretches out*

Why is she still here?  Food Lady, ain’t you got bacon to fry?

OK, so I know I’ve said before that Chevy sleeps like the living dead.  She’s completely deaf (yes, deaf as she cannot hear) so when she’s asleep, usually the only thing that wakes her is a vibration.  Or a cute Chasey Bear pouncing on top of her.  But I say “living dead” because she never closes her eyes when she sleeps.  It’s so gross.  She has something like a third eyelid or some kind of membrane that slips over her eye and it’s just so blech but I couldn’t help it.  I had to do it. 

Internet, I present to you: Zombie Dog.

ZOMBIE DOG!!!

In part 1, we looked at setting up MSpec and writing our first specifications.

Now we get on to the all important implementation stage.

We ended up with these basic specifications by the end of part 1.

Lets start by implementing the first one (when product search page requested).

On first glance, the wacky syntax here might put people off. However, once you start writing these tests you tend to see past it to the specs and the tests themselves.

We start by establishing the context for our test, what we need for this test to actually run. In this case it’s the product controller that we’re testing, and so it makes sense to instantiate the product controller and assign it to a field for use within our tests.

Next we need to actually do something, perform the action which we are testing. In this case we’re talking about the user visiting the “product search page” so I will set up the test to call an action on the product controller called Search.

Note how we have created a Because statement. In BDD terms this is the behaviour we are testing. As with the controller I store the result of calling this action in a field so we can use it elsewhere in the test.

At this point I should point out that in the spirit of TDD, I am only doing enough at this point to make this compile. So our Product Controller currently looks like this.

Jumping back to our test, lets test that the behaviour under test (search) does what we expect.

Using an extension method (thank you James Broome and JP Boodhoo) we can simultaneously check that our result is a view and also get a typed reference to the result (as a ViewResult).

Now we make the test pass.

Finally we run MSpec and marvel at the results

We still have several not implemented specs, but the one we have implemented now appears as a simple line of text. If there were any problems with the test (if it failed) we would see a red error message by the failing specification.

In part 3 we’ll look at more complex controller actions and introduce Rhino Auto Mocker.

I read in the newspaper today that this girl who suffered from BDD  has managed to overcome this problem by looking at pictures of herself looking good,  smiling and so on. I think it is a great idea for anyone with an image problem. Looking in a mirror seems to accentuate all our physical blemishes and so by admiring yourself on  a photograph,  you are actually doing the stuff that we do when we look at a celebrity in the tabloid or magazine.

Worth trying.

I’ve long been a fan of test driven development in theory but in practice have experienced many of the issues which turn people off TDD and unit testing in general.

Brittle tests which do too much, tell you very little about the meaning behind the code and are more a hindrance than a help when it comes to making changes at a later date.

Well as you may have guessed, given the title of this post, I have found an answer to these problems in the form of BDD using MSpec and Rhino Automocking. I have been using this approach for a good while now and continue to be pleasantly surprised by just how much fun it is writing my tests, but also how stupidly easy they are to change, and how well they document my project’s requirements.

Update: You can now download the compiled latest release of MSpec directly.

External Tool

It’s a good idea to set up an external tool in Visual Studio to run your MSpec tests and produce html output.

Create a new external tool which launches mspec.exe with the following arguments.

$(TargetName)$(TargetExt) --html "$(ProjectDir)\Report.html"

Make sure the initial directory is $(BinDir) and tick Use output window.

Using your favourite Test Runner

Included in the MSpec download are scripts to configure various test runners to recognise and run MSpec tests.

Simply run the bat file which relates to your build runner and way you go!

Writing Specifications

Ensure you add a reference (in your Tests Project) to Machine.Specifications.dll.

Now the fun begins.

I’ve created an ASP.NET MVC site and empty class library Tests project.

Let’s say we want to create a simple page which allows users to search for a product.

We’ll start by creating a new folder in our tests folder called Controllers and add a new class file called ProductControllerTets.cs

Having discussed this feature in detail with the client, I’ve a pretty good idea of what they want, so I start with the following.

What I particularly like about this, is that you can really think about exactly what you’re doing and express it in code which will eventually become executable tests without actually implementing any code (yet!).

If we now build our test project and run the tests using the console runner via the external tool we set up earlier), we’ll get a report.html file in the tests project which looks like this…

In part 2, we’ll start implementing these tests.

In part 3, we’ll introduce Rhino AutoMocker.

Following on from his successful speaker spots at Skills Matter’s Progressive .NET tutorials earlier this year, the talented Mr David Laribee will be hosting a 2-day course at the new Skills Matter eXchange in December.

Over the course of two days we’ll engage in a diverse array of discussions, exercises, and summary talks aimed toward aspiring and existing technical leads, senior developers, coaches and architects. Participants will leave with actionable techniques and tools for leading their teams toward greater throughput and technical excellence.

In Mr Laribee’s own words “We need leaders that can get down and dirty with technology while mentoring and leading people while staying true to product vision. We need an embedded role in software teams like Toyota’s Chief Engineer: someone who brings skill and experience to bare in all areas of product development, product design, user experience, coaching, software craftsmanship, et. al. “

Places are filling up fast — so make sure you don’t miss out on yours: book before November 15 and pay only £550+VAT per delegate (RRP: £990).

For more information and to book visit the Skills Matter site and get your place.

In the brain of Elizabeth Keogh: tonight’s free “in the brain” session at Skills Matter is with Elizabeth Keogh and is called “BDD: A Lean Toolkit”.

In this talk, Liz Keogh looks at BDD as a Lean toolkit, how to use BDD in conjunction with other Lean tools like Kanban and Value Stream Mapping, BDD anti-patterns, and some pragmatic tips for making BDD flow.

Liz currently works as an independent Agile Coach and trainer based in London. She is a well-known blogger and international speaker, a core member of the BDD community and a contributor to a number of open-source projects including JBehave.256256256

For more info and to register for the event, visit Skills Matter and sign up — but hurry, spaces are limited and the event starts at 1830 this evening!

My favourite java testing framework, jbehave, released a new version a couple of weeks ago. New improvements that I like include:

• @Named annotation for parameters allowing you to step parameters any way you like
• @Alias annotation allowing you to match multiple scenario lines to a single Step implementation
• GivenScenario keyword allows you to include another scenario as prerequisite.

I am excited to see that development of the jbehave framework is not merely sustained. The framework is constantly being improved and new features being introduced.

Ce week-end nous avons été invités à déjeuner chez des amis de ma femme. Ils étaient plus jeunes que nous et avaient des points de vue idéalistes sur à peu près tout : le gouvernement c’était de la merde, les flics c’était des schmidt, les pollueurs des enculés. J’ai eu l’impression que j’assistais à un concert de Sinsemilla. Autant dire qu’une fois que je leur ai demandé de me regarder afin de leur montrer que je n’étais pas un trafiquant d’armes, ma réserve de blagues était épuisée. Je ne sais pas gérer ce public là moi.

Je me suis fait chier copieusement mais, et c’est important parce qu’elles immortalisent le moment, j’ai réussi à tromper mon monde sur les photos.

Le calvaire s’est prolongé jusque dans le métro puisque Kevin et Jane prenaient la même ligne que nous.

“Kevin et Jane” quoi… A mon époque, les seules personnes qu’on pouvait voir avec des prénoms pareils c’était les personnages de Dynastie.

La différence d’âge et de sagesse nous séparant était trop flagrante. Je profitais d’un moment de silence pour laisser mes yeux se promener sur la banquette d’à côté où était échoué un programme TV. Au dos de ce programme, une publicité.

Kevin, récemment diplômé de son école de commerce, cru sentir un intérêt dans mes yeux. Il me dit :

Vous savez Mr Morisset, moi aussi j’aime bien ce genre de trucs!

Moi j’aime surtout qu’on m’appelle “Docteur”.

J’ai fait marketing à l’école. Ça me fascine ce genre d’opérations. Je peux pas m’empêcher d’imaginer quel est le taux de retour. En termes de BDD ça doit être énorme.

Je ne savais pas ce que le mot BDD voulait dire. Je le regardais sans rien dire, avec un sourire plus poli qu’approbateur. Les maigres espoirs que j’avais en Kevin s’envolaient avec ses paroles. Mais qu’est-ce qu’on était en train de foutre avec des tocards pareil?

Bien loin de moi l’idée de juger les passions des autres, chacun aime ce qu’il veut. Mais personnellement le premier truc auquel je pense en voyant cette pub c’est de m’imaginer la tête des gens qui achètent le foie gras uniquement dans le but de récupérer la montre (bracelet cuir) et le service à fromage (en bois).

EXEMPLE

Il finit de m’achever, passant du coq à l’âne, en disant qu’il avait vu “This is it” mais qu’il regrettait que ça ne soit pas en version française. Il rajouta que c’était dommage que les films soient en V.O. au cinéma. Je serrais les dents pour garder le contrôle de mes nerfs. Je ne connaissais pas cet abruti. J’allais bientôt ne plus jamais le revoir de ma vie. Il n’était pas nécessaire de gueuler en plein dans le métro.

Mais je l’avais mauvaise. Car la version française, ça fait mal. Je repense particulièrement à la version française du Big Legowski.

Ou à celle du Shining.

Globalement La Vie est Belle n’avait aucun intérêt en Français non plus.

Même les publicités doublées sont nulles.

C’est vrai, le métier de doubleur n’est pas facile. Il faut qu’il s’approprie le personnage, la scène. Ce n’est pas toujours évident. Certains films s’en sont pas mal sortis. Je pense au premier Batman ou à la trilogie des Retour vers le Futur. Mais dans l’ensemble la version française est une abomination.

Au moment de se dire au revoir, je dis quand même à Kevin que c’était bien la peine de faire chier avec un prénom pareil.

Une fois rentré dans l’intimité de notre chez nous, autant dire que j’ai demandé des explications à ma femme dans l’unique langue que cette petite garce comprenne : la langue de la castagne.

Yes I am going to write another blog posting singing the praises of test first development (be it TDD, BDD or whatever DD is cool now).  What will be new is that I’m going to compare it to something that I avoided doing for almost 36 years on this planet, flossing my teeth regularly.

Six months ago I was told by my dental hygienist that my gums were not doing so well in terms of health.  This made for a somewhat uncomfortable (ok it was downright painful) dental cleaning.  She said that flossing was really the key to keeping my gums healthy, keeping my teeth in my mouth and making visits to the dentist more “enjoyable”.  I took it upon myself to help myself by flossing more regularly.  Yes I missed a couple of days but for the most part I flossed every day.  It really only takes 5 minutes at most to do a good job in there…which you can easily make up by reading 5 less minutes of the Internet (or at least this is how I found the time).  Today’s cleaning was a breeze compared to last time.  Yes it was still a little uncomfortable but nothing compared to the last time.

So what does this have to do with test first development?  We’ll just this morning (before the dentist’s visit) I was in the process of refactoring a bunch of Rails code to add a new object hierarchy for some new requirements.  To make a long story short, my refactoring broke a bunch of code (as one would expect).  Thanks to our suite of existing spec code, I now had a laundry list of tasks that were needed to properly integrate the new code.  After addressing all of them and tweaking some views (we don’t have view specs but hey nobody is prefect), I fired up the app and it all just worked.  Until I started working on Rails sites, all of that spec code would not have existed.

I couldn’t imagine what might have happened had we not taken the TFD (test first development) route with this project.  Yes it takes a little more time up front to write the tests (just like flossing) but the next time you have to do some major work in your application (which is regular just like visiting the dentist’s office)  the experience won’t be as painful as it could be.

Today’s experiences with TFD as well as the dentist office have made me a firm believer that both regular TFD and regular flossing makes my life a little easier.  I vow to no longer look at writing tests as wasted time but an investment in pain saved down the road.  I hope that anyone that reads this either starts doing test first development, or maybe even flosses a little more regularly and uses this analogy when preaching the wonders of TFD.

– Mike Gehard

My current project team has been eating its vegetables.  Has yours?

Selenium is a great tool for testing webapps from a true browser driven user’s perspective.  By driving most mainstream browsers via a core Javascript library, a Selenium script can easily test how your app behaves (or misbehaves) just like a real user would see.

“Webrat lets you quickly write robust and thorough acceptance tests for a web application.”  Written in Ruby, Webrat allows acceptance tests to exercise an arbitrary web application through its Selenium integration, or Rails apps without starting a server.

Cucumber allows code to be written in a simple domain specific language (DSL) that anyone can read.  Layer Cucumber on top of Webrat and Selenium, and you have User Acceptance Tests (UATs) that the client can read (and ideally write), that the entire development team understands, and which can be run as BDD or regression tests.

Cucumber example taken from cuckes.info

Without going into the details of how each of these libraries work, below are some of my notes, tips, and impressions of using Cucumber to write UATs for a greenfield Java EE application over the past ~10 weeks.

• Ideally, each test would run in its own transaction so that they wouldn’t interfere with each other and could be run in parallel.  Using Cucumber (Ruby) to test a totally separate web application running on Tomcat (Java) presents a problem.  The team debated several possible solutions using JRuby and having the Cucumber build spawn an embedded Tomcat instance but decided that the cost outweighed the benefit to the current project.
• Since we were forced to use pure JDBC by our client, we decided to use ActiveRecord migrations to build our tables, and generate SQL which we could re-leverage from our Cucumber tests.  Custom creation Webrat steps were written to push setup test data for each model.
• DB2 support with the Ruby ActiveRecord drivers is lacking proper install instructions on Linux (damn thing requries a full DB2 install to run). By leveraging JRuby, we were able to use the DB2 JDBC drivers instead which worked much better (without installing DB2).  Getting Cucumber, Webrat, and Selenium running in JRuby took a bit of finesse and shebang wrangling but eventually worked.
• Outputting Cucumber results to a JUnit style XML output made our integration on our Hudson CI server simple and easy to read. (The Chuck Norris plugin helps too)
• We tag each test with a story number (e.g. @10045) so that we can quickly run all tests for a given feature easily: cucumber –tags @10045.
• Our QA lead works to define and write-up our Cucumber tests during pre-iteration planning and before each story enters our work queue (the team uses a modified Kanban board approach to pull work through each iteration, Cucumber is our first queue).  When she has a test written, she will tag it with @in-process to let us know that it is ready to be worked on, but not yet implemented.
• We have custom Rake tasks to run all of our “finished” tests as well as just our “in-process” ones.  The in-process task will fail if any tests pass (they should be marked as finished).  Unfortunately this rake task doesn’t work with the Hudson/JUnit build.
• Ongoing issues we still struggle with are:
  • making sure that small variations in DSL verbiage don’t muddy up our tests (it is easy for the team to accidentally end up with two different commands which do the same or similar actions without a clear distinction)
  • cross browser and separate environment testing happens on different dedicated servers on dependent builds so that they don’t end up stepping on each other
  • as it is with any testing library, care needs to be taken to keep only common tests grouped together and setup/background work common to all tests that NEED it.  Pushing too much work into common actions results in slow tests
  • Tests are supremely faster and more valuable than manual tests, but are not as fast as JUnit tests and will never replace manual exploratory testing.

Overall the team has been very pleased with our ability to drive our development from the tests and verify that new changes don’t break existing functionality from the users’ perspectives.

* Another Asynchrony team is working on leveraging Cuke4Duke to do similar testing of a Java thick client.  Should be interesting.

Edit: Thanks to Amos King for some proof reading help.  You can find his blog over at Dirty Information.

So, I have done one presentation about Test Driven Development yesterday, touching TDD concepts and also lots of concepts about Behavior Driven Development (BDD).

There are simple concepts about the test first process. You have to write a test that fails, write code to make the test pass and then refactor your code. Keep the bar green to keep the code clean, remember this.

Repeat this cycle until you don’t have anything else to test for a specific feature.

Looking at a User Story and its acceptance tests, you also have to make sure you are adding business value on every test.

Simple right?

Well, you have to practice.

A lot.

Really.

I’m not kidding.

Believe me.

By the way, don’t leave technical debt behind.

Just for information, currently I manage teams developing in Java (Web), Java (Mobile) and Delphi (Desktop/WebBroker).

Looking at Java Web, I’m starting to teach teams how to use JUnit for automated unit tests, and code coverage with Emma and EclEmma (Eclipse Plug-in).

For Java Mobile, the solution will be based on J2ME Unit and Cobertura for Java ME.

And Delphi, we are going with DUnit and Delphi Discover, a Coverage Tool for Delphi programmers.

And also looking at test automation, both Delphi and Java Web apps will use Selenium to help on automation of web processes.

Well, you can wait more articles on each of those tools and relation to Agile Development and eXtreme Programming practices.

So, remember: you are build tests for prevention of defects. With this you are also building tests to do regression testing.

Keep quality high, always.

En la semana del 6 al 9 octubre tuve la oportunidad de presenciar las charlas de la jornada latinoamericana de Agiles 2009 y el curso de TDD dictado por Naresh Jain. Fue una excelente experiencia, no solo por el valor técnico si no también por la calidad humana y disposición de cada uno de los disertantes y organizadores para satisfacer cada una de las inquietudes.

El curso de TDD fue muy bueno, Naresh demostró la importancia de tener un mecanismo de evaluación constante y automatizado para tener siempre una retroalimentación del estado del producto, aplicó el concepto de TDD con analogías sencillas sin alejarse de los casos reales de desarrollo de software y fue muy pragmático todo el tiempo.
Al finalizar el curso, salí con una idea mucho más clara sobre el significado de Unit Testing, sus beneficios, mitos y limitaciones. Los temas que se tocaron fueron en un principio XP, Pair Programing, Metodologías Agiles, Test Driven Development, Test Driven Design, Code Smells y Automated Refactoring, para después sumar herramientas para aplicar tanto TDD como BDD. Entre cada tema se plantearon cuales son los errores comunes, los patrones de diseño y las implementaciones en diferentes lenguajes: Java, .Net principalmente, pero sin dejar de lado Python, C/C++, Ruby entre otros. Cabe destacar que por la cantidad de los temas tratados, todos los participantes concluimos que el título designado “Test Driven Development (TDD) and Refactoring” no era el adecuado, puesto que el mismo no daba a conocer la totalidad de la temática del curso.
Los seminarios que presencié los días restantes fueron muy variados.
Los mas destacados fueron:
* A cargo de Alejandra Alfonso y Emilio Gutter escuché sobre experiencias en implementaciones de metodologías agiles en un grupo multicultural y remoto.
* Un Coding Dojo y un Testing Dojo, el CO a cargo de Ivan Sanchez y Victor Hugo Germano y el TO a cargo de Jorge Alberto Diz, ambos excelentes.

Todo esto potenciado por la participación de Brian Marick, Diana Larsen, Roy Singham, David Hussman, Joshua Kerievsky, Dave Nicolette y sus respectivos key note, cursos y/o charlas.

En conclusión, una experiencia muy completa desde lo profesional y lo personal de la que no dejé de aprender en cada minuto.

Espero poder sumarme al equipo y vamos por Agiles 2010 empujando los limites tecnológicos de América Latina demostrando que acá también podemos tener eventos de vanguardia y de excelente calidad.

Un ‘mil gracias!’ para todos lo que hicieron posible Agiles2009 en especial a Alejandra Alfonso, a Juan Gabardini, a Victor Hugo Germano por la buena onda. Y uno mucho mas especial a Romina Cordoba, que sin ella no podría haber participado de todo esto

No último Post tivemos uma visão inicial do uso de Specs, BDD e um exemplo de utilização do framework. Mas como você deve ter percebido, as especificações eram blocos de códigos ainda soltos no Post. Specifications são objects ou classes Scala, vejamos como declarar a especificação do post anterior, configurar uma sessão Lift, criar um contexto de execução das especificações, e por fim estender o framework Specs com Matchers personalizados.

object TodoSpec extends Specification with Contexts {

    "Create/Update a ToDo item" should {
       //... spec from last post.
    }

   //Inicia um sessão Lift
    val session = new LiftSession("", StringHelpers.randomString(20),
                                                new MockHttpSession, null)
   //Executa a dentro da sessão Lift
   def inSession(a: => Any) = {
        S.initIfUninitted(session) { a }
    }

   //Novo usuário para execução da especificação
    def loginUser = inSession {
        val user = User.create
        user.email("tester@gmail.com").password("xxxxxx")
        user.save
        User.logUserIn(user)
    }

    //Contexto de execuão da Especificação
    new SpecContext {
        //Estabelece Conexão com o banco antes da execução.
        beforeSpec {
            if (!DB.jndiJdbcConnAvailable_?)
            DB.defineConnectionManager(DefaultConnectionIdentifier,
                                                     DBVendor)
            loginUser //Acontece o login do usuário
        }
        aroundExpectations(inSession(_))

        //Remove o usuário de teste
        afterSpec {
            val user = User.find(By(User.email, "tester@gmail.com"))
            User.delete_!(user.open_!)
        }
    }
}
class TodoSpecTest extends JUnit4(TodoSpec)

Uma especificação é um objeto que extends a classe org.specs.Specification. Specification oferece um conjunto de conversores implícitos para Strings, por isso os métodos should, in e >> aparentam serem invocados a partir das strings que descrevem a especificação.

Como todo teste que deve acontecer dentro de um contexto (jndi, spring, hibernate, ejb3, etc), precisamos de um código extra para usarmos recursos do Lift e definir um contexto para a execução da especificação. Por isso, aqui usamos a trait Contexts e criamos uma nova instância de SpecContext com os métodos beforeSpec fazendo a conexão com a base de dados e aroundExpectations garantindo que a especificação ocorra dentro da sessão Lift criada.

Com Specs, você pode visulizar o resultado das execuções na sua IDE como se fossem testes JUnit. Por isso a TodoSpec é um objecto e há uma classe TodoSpecTest que extends org.specs.runner.JUnit4. O objeto da especificação é passado como construtor do runner de JUnit4. Assim temos a execução da especificação integrada com a IDE. Veja outras formas executá-las aqui.

Usamos o próprio Lift Test Kit  uma instância de HttpSession (new MockHttpSession), assim podemos instanciar corretamente uma sessão Lift.

Para a execução dos testes vamos precisar das dependências abaixo. Lembre-se de instalar no seu repositório local Maven a versão SNAPSHOT do Specs 1.6.1 encontrado aqui.

        <dependency>
            <groupId>org.scala-tools.testing</groupId>
            <artifactId>specs</artifactId>
            <version>1.6.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>net.liftweb</groupId>
            <artifactId>lift-testkit</artifactId>
            <version>1.0</version>
            <scope>test</scope>
        </dependency>

Outro ponto importante do framework Specs, é a sua extensibilidade. Podemos criar Matchers tão poderosos quanto queiramos para oferecer um melhor suporte à linguagem única utilizada no negócio do sistema. Supondo que a especificação descreva que um usuário logado no sistema deve ser um usuário Gmail, podemos criar nosso próprio matcher para tornar nossa especificação mais natural. Vamos adicionar o seguinte sistema para especificar o comportamento do nosso matcher, facilitando o entendimento:

    "A logged user" should {
        "be a Gmail user" in {
            val user = User.currentUser.open_!
            user.email.asString must beAtGmail
        }
    }

beAtGamil é um matcher definido em um object que pode conter diversos matchers customizados. Até aqui temos apenas um matcher:

object CustomMatcherSpec extends Specification {
    "beAtGmail" can {
        "assert users at Gmail" in {
            "paulosuzart@gmail.com" must beAtGmail
        }
    }
}

object CustomMatcher {
    import java.util.regex.Pattern
    val beAtGmail = new Matcher[String]{
        def apply(m : => String) = {
            val pattern = Pattern.compile(".+\\@gmail.com")
                                      (pattern.matcher(m).matches,
                        m + " is at Gmail",  m + " is not at Gmail")
        }
    }
}
class CustomSpecTest extends JUnit4(CustomMatcherSpec)

Não podemos esquecer de um executor JUnit4 para a integração com a IDE. Seguindo os passos do post passado, você pode ver o resultado das especificações do sistema ToDo e a especificação do Matcher customizado.

BDD é sem dúvida uma metodologia com grande potencial de expansão no mercado e torço pra que muito em breve apareçam oportunidades com tecnologias e metodologias como essas.

Ainda não sei dizer em qual a dimensão de projeto o BDD é mais apropriado, talvez as mesmas dimensões onde TDD e DDD são aplicáveis.

Detalhes como as classes DB, S e todos os fontes do Post, você vai encontrar na aplicação disponibilizada no meu repositório github. Reforço que o projeto froi criado seguindo o tutorial de Getting Started do Lift e modificado para a construção do Post. E não se esqueça de me seguir no Twitter.

“That boy’s got a lot of quit in him” – Ron White

My ex-husband used to tell me I had an absurd sense of self-entitlement, usually when I was bemoaning my writing “career”, or lack thereof, or whining when I wasn’t allowed to buy something frivolous, like shoes. His turn of phrase was both wrong and right with regard to my writing – I ought to actually do enough of it, and then make efforts to disseminate it, before I could justifiably complain that my genius is being ignored. However, I’ll never not believe that it’s not self-entitlement on my part, but a frustration with how the movie industry runs vs. how it was purported to run based on the flattery offered me by the higher-ups at my film school. They made sure I got my money’s worth by filling my head with compliments, and good on them … except compliments get you nowhere if your daddy doesn’t know someone (or is someone.)

Oh, and then there’s the lassitude. I’m full of lots and lots of lassitude. It’s a fancier, SAT-approved way of saying I’m fucking lazy. I can’t be bothered to force myself to write. If it isn’t surging from my strong pen hand, it isn’t happening.

The ex was wrong about self-entitlement vis-à-vis purchases. There is never anything frivolous about a great new pair of shoes.

I am catching up with an old e-acquaintance’s blog, which is epic and incisive and beautifully written, and I am finally filled with a yen, an actual yearning to write something. I’ve already started two blogs. One is on hiatus, until the boyfriend and I can really sit down and hash out its direction and beef up the content before putting up live and out there. The other, I haven’t even begun but I will … as soon as we watch those first two movies from Netflix that have been sandwiched between Myra Breckinridge and Garlic is as Good as 10 Mothers atop the VCR. I swear.

This blog will be different. Solely mine. Solely self-indulgent. To all the things I “used to”, before I let the “quit” get too settled in my soul. I turned 31 last week. No one came out to the bar I selected for my celebration. Whatever it is, I’m doing it wrong. Time to make a change.

I used to be married. You can already see how well that turned out.

I used to write prolifically, and well (if I may say so myself.) I wrote screenplays and blog posts. Now I can barely be bothered to write a two sentence e-mail response because I’m afraid I have nothing of interest to say.

I used to have friends. But I’m lazy, and a homebody, and I refuse to drink and drive, and so I don’t really know that I do have friends anymore (aside from online conveniences, namely the popularity contest/24-7 high school reunion that is the Facebook.)

I used to weight 5 pounds less, back in April. I’m sure I’ll expound upon how much this (stupidly) weighs on me in the future. PS: please note expound and weighs were not used on purpose but I noticed anyway.

I used to do yoga with enthusiasm. I can, thank god, still put my hands flat on the floor when bending forward. But my flexibility is waning, fast, and I’m possibly more disappointed with myself for this than for other, seemingly more important things.

I used to like my job. Between the approach of the industry’s fallow season and, frankly, taking on a job that pays well enough but could be done by a chimpanzee with a headset, I am stultified. Not to mention at the office at odd hours (to wit, I’m in hour 6 of my Sunday shift. I’m wearing two-day old jeans, because no one else will be here, yet I dried my hair in the ladies’ room because I didn’t want it to dry funny. Yesterday, my jeans were fresher, but my hair was not.)

I used to think that, despite my cynicism and lack of motivation, I could someday, somehow, be a beautiful and unique snowflake, that Tyler Durden’s bitter bullshit was just that. I’m pretty sure now that not even my family would notice if I died tomorrow, and all I’ll leave behind are my beloved cats and some fractured scribblings here and there. Well, and a fierce shoe collection.

I used to go to therapy, until I broke up with that bitch for spending my sessions showing me pictures of her doggie, rather than talking about my divorce or the body dysmorphic disorder and acute depression she’d just diagnosed (and doomed – let’s hear it for our country’s health care, and appreciation/understanding of mental … deficiencies!) me with.

Here’s hoping this is a home for some of my vitriol, because it’s eating me up inside without the side benefit of gnawing away at some of my portlier physical attributes (see what I did there? Tying it back in with how I see myself … oh never mind. You’ll never hear the end of it and neither will I.)

Pra variar um post sem ligação alguma com o anterior. Mas vamos lá.

Há pouco mais de um ano que comecei a estudar Scala, e durante este tempo e me dediquei quase que puramente à linguagem. O máximo que brinquei foi com Scala SBT, o Dispatch do n8han e outras coisinhas. Acredito que até mesmo por não ser meu foco profissional (por hora) demorei pra estudar o Lift, o framework MVC para Scala.

Completei o getting started do framework e comecei a fazer uma segunda aplicação de estudo com @lucastex e @r4f4e1. Mas o motivo desse post é um processo de desenvolvimento que me chamou a atenção depois que vi o Cucumber. BDD, ou BehaviourDrivenDevelopment é uma metodologia ágil que vem como um complemento – ou mesmo evolução – ao TDD (Test Driven Development) e se transformando em uma ferramenta primordial para o DDD (DomainDrivenDesign).

Existem muitos frameworks BDD como RSpec, Specs, Scala Test, Cucumber, JBehave, jsspec, e escolhi o Specs por algum motivo obscuro.

Sendo bem objetivo e tentando reduzir a quantidade de palavras no post (deixando o máximo de código possível), o foco do BDD é a construção de comportamentos esperados para o sistema ao invés de testes. A construção de testes, em última instância, tem interesse em verificar o comportamento que o sistema deve (should) ter em diversos cenários (examples), por isso BDD.

Outro ponto importante é a tão falada linguagem ubíqua, ou seja, uma linguagem que todos os envolvidos na construção do software consigam entender. Frameworks BDD permitem que esta linguagem seja executável e escrita na propria linguagem de construção do sistema. Scala é muito poderosa na construção de DSLs (Domain Specific Languages), chegando ao ponto do código se parecer com uma escrita em ingles, não em uma linguagem de programação. Neste post, o comportamento que escolhi especificar foi de validação de dados de domínio:

    "Create/Update a ToDo item" should {
        "show the following error messages:" >> {
            "Description must be 3 characters" >> {
                "if description field length is less than 3" in {
                    val todo = ToDo.create.owner(User.currentUser)
                    todo.desc("").validate must
                    contain(FieldError(todo.desc, Text("Description must be 3 characters")))
                }
            }

            "<b>Priority must be 1-10</b>" >> {
                "if priority field is not between, including, 1 and 10" in {
                    val todo = ToDo.create.owner(User.currentUser)
                    todo.priority(-1).validate must
                    contain(FieldError(todo.priority, <b>Priority must be 1-10</b>))
                }
            }
        }
    }

Nos parágrafos acima note em negrito as palavras should e example. Indicamos com should o que o sistema (ToDo app) deve fazer nos (in) exemplos, ou cenários, que seguem.

Dada cada uma das mensagens esperadas, o trecho de código delimitado por in {…} é implementado com um ou mais matchers.  o matcher must contain é usado aqui por que o método de Validação de uma classe mapper no lift retorna um List[FieldError]. FieldError é uma case class de construção FieldError[Identifier, NodeSeq]. Logo, o matcher must contain verifica a existência de um objeto com o formato especificado na lista de erros retornados na validação.

Logo, os matcher são os responsáveis por assegurar que a especificação descrita no texto será atendida pelo resultado do código nos exemplos.

O guia de matchers apresenta uma listagem completa desta DSL que pode ser aplicada em Iterables, String, Objects, Maps, Numer, Options, ScalaChecks, XML, Arquivos e grafos de objetos. E para ilustrar o uso de matchers para string.

Ao executar a especificação acima, temos o resultado:

-------------------------------------------------------
Running com.liftworkshop.todo.TodoSpecTest
Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 2.694 sec <<< FAILURE!
Running com.liftworkshop.todo.AppTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.042 sec

Results :

Failed tests:
  Create/Update a ToDo item should show the following error messages: Description must be 3 characters if description field length is less than 3
  Create/Update a ToDo item should show the following error messages: <b>Priority must be 1-10</b> if priority field is not between, including, 1 and 10
  Create/Update a ToDo item should show the following error messages: <b>Priority must be 1-10</b> if priority field is not between, including, 1 and 10

Tests run: 5, Failures: 3, Errors: 0, Skipped: 0

Isto por que os campos desc e priority (mostrados abaixo) não implementam nenhuma validação:

class ToDo extends LongKeyedMapper[ToDo] with IdPK {
    lazy val priorityList = (1 to 10).map(v => (v.toString, v.toString))

    def getSingleton = ToDo

    object done extends MappedBoolean(this)
    object owner extends MappedLongForeignKey(this, User)

    object priority extends MappedInt(this) {
        override def defaultValue = 5

        override def _toForm = Full(select(ToDo.priorityList,
                                           Full(is.toString),
                                           f => set(f.toInt)))
    }

    object desc extends MappedPoliteString(this, 128)
}
object ToDo extends ToDo with LongKeyedMetaMapper[ToDo]

E aqui chegamos a um ponto interessante do BDD, certamente herdado do TDD: vamos escrever o código estritamente necessário para atender a nossa especificação. Supondo que você tenha o mínimo de conhecimento com Lift e quem sabe tenha feito o getting started, adicionemos as validações assim:

    object desc extends MappedPoliteString(this, 128) {
        override def validations = valMinLen(3, "Description must be 3 characters") _ :: super.validations
    } // para o mapeamento da descrição e ...

    object priority extends MappedInt(this) {
    ...
        override def validations = validPriority _ :: super.validations

        def validPriority(in : Int) : List[FieldError] =
        if (in > 0 && in <= 10) Nil
        else List(FieldError(this, <b>Priority must be 1-10</b>))
    ...
    }

O método validations é redefinido em cada propriedade mepada que necessida validação. O campo desc apenas obriga o tamanho mínimo para 3 com a mensagem especificada definido pela função utilitária valMinLen. Já o campo priority instancia diretamente um FieldError passando o campo contendo o erro junto com a mensagem em negrito.

Este projeto foi montado usando o NetBeans junto com o Maven conforme descrito no getting started do Lift. Fazendo um pequeno ajuste (descrito no próximo post), temos a execução da especificação integrada ao JUnit na IDE NetBeans.

Executando outra vez a especificação, teremos todos os testes ok como na figura a seguir. Um print do Netbeans.

Especificação atendida!

Esta foi talvez a parte mágica da coisa. Onde tudo já está funcionando e precisamos só curtir o BDD num exemplo sofrível com intuito de ilustrar esta metodologia, o framework Specs, o framework Lift e a linguagem Scala.

O código completo do projeto estará disponível no próximo Post desta série. As versões utilizadas no projeto são: Lift 1.0, Scala Specs 1.6.1, EasyMock 2.5.2 (instalada no repositório maven local). E no próximo Post teremos: Configurando seu projeto Maven para o uso de Scala Specs; Explorando mais matchers; Configurando Contexto Specs para execução da especificação em uma LiftSession acessando a base de dados; Especificando Snippets Lift, e mais. Será que cabe tudo em mais um Post? Vai ter que caber.

Se puder visite o site do BDD e conheça mais sobre esta metodologia no mínimo interessante. Dado que não sou especialista em nenhum metodologia ágil, se você tem ou teve alguma experiência prática com BDD, TDD ou DDD deixe seu comentário ou sua sugestão sobre como abordar o tema de maneira mais prática.

Veja a Parte II deste post.

L’application permettant de scanner ces code-barres 2D interactifs est désormais compatible avec ces deux familles de smartphones. De quoi assurer le décollage de ce nouveau support de communication ?

Nouvelle étape pour l’écosystème des codes-barres 2D interactifs. Après Mobiletag, l’AFMM (Association Française du Multimédia Mobile) annonce ce lundi la mise à disposition gratuite de l’application flashcode sur l’AppStore (iPhone) et l’Android market. Elle était jusqu’à aujourd’hui disponible pour les mobiles sous Windows Mobile, Symbian ou sBlackberry OS.

Baptisés flashcode ou mobiletag, ces codes-barres 2D qui peuvent être placés sur n’importe quel support (une affiche, une page de journal…) ont un principe commun : photographiés par un terminal compatible (intégrant donc un logiciel dédié), ils renvoient vers un contenu multimédia mobile (site internet, publicité…).

70% de smartphones compatibles

Le scan peut également déclencher l’envoi d’un SMS, d’un MMS, d’email ou un appel voix. On imagine alors les possibilités pour les spécialistes du marketing. “A l’heure où de plus en plus d’attention est portée à l’iPhone, la présence de l’application flashcode sur l’AppStore était attendue par de nombreux annonceurs”, commente l’AFMM.

Pour l’utilisateur, il s’agit d’accéder plus simplement à des contenus. Pour l’opérateur, le flashcode est un levier de trafic sollicité (ce qui est important en termes d’acceptation du message).

Désormais, près de 10 millions de téléphones mobiles et 70% des smartphones  sont aujourd’hui compatibles flashcode, ajoute l’association.

Depuis deux ans, les expérimentations liées à ces codes-barres 2D se multiplient. Dernière en date, l’Hyperlivre développé par Orange et Robert Laffont. L’ouvrage est truffé de flashcodes renvoyant vers des contenus supplémentaires multimédias.

Il y a un an, les magazines Public, Closer et Voici ont ainsi proposé à leurs lecteurs d’accéder à du contenu exclusif via leur téléphone mobile grâce aux codes 2D.

Résultat des courses, sur les 2 millions de personnes possédant un combiné compatible, 30.000 demandes de téléchargement de l’application flashcode ont été enregistrées.

Source : BusinessMobile

A propos de la solution TooFAX® :

TooFAX® est une solution moderne et innovante de fax dématérialisé, vous permettant l’envoi, la réception, et la sauvegarde de fax par internet ou par e-mail. Depuis votre ordinateur de bureau ou portable, votre PDA, etc, TooFAX® vous permet d’effectuer des opérations de faxing sur les 5 continents.

TooFAX® est la synthèse entre les atouts du Fax (rapidité, valeur juridique) et l’aspect pratique de l’e-mail.

Actualité de TooFAX® :

- Site internet : http://www.toofax.com

- Site du service : http://www.service.toofax.com

- Vidéos de démonstration : http://www.video.toofax.com

- Groupe Facebook : http://www.facebook.com/toofax

- Club des utilisateurs de la solution : http://www.club.toofax.com

- Actualités en ligne des services TooFAX® :  http://twitter.com/toofax

- Blog  officiel de la gamme de services TooFAX® : http://toofax.wordpress.com/

- Base de données gratuite de n° de fax pour vos opérations de faxing : http://www.toofaxdata.com

Source : ZDnet

A propos de la solution TooFAX® :

TooFAX® est une solution moderne et innovante de fax dématérialisé, vous permettant l’envoi, la réception, et la sauvegarde de fax par internet ou par e-mail. Depuis votre ordinateur de bureau ou portable, votre PDA, etc, TooFAX® vous permet d’effectuer des opérations de faxing sur les 5 continents.

TooFAX® est la synthèse entre les atouts du Fax (rapidité, valeur juridique) et l’aspect pratique de l’e-mail.

Actualité de TooFAX® :

- Site internet : http://www.toofax.com

- Site du service : http://www.service.toofax.com

- Vidéos de démonstration : http://www.video.toofax.com

- Groupe Facebook : http://www.facebook.com/toofax

- Club des utilisateurs de la solution : http://www.club.toofax.com

- Actualités en ligne des services TooFAX® :  http://twitter.com/toofax

- Blog  officiel de la gamme de services TooFAX® : http://toofax.wordpress.com/

- Base de données gratuite de n° de fax pour vos opérations de faxing : http://www.toofaxdata.com