Chronicles of a build - the signup plugin 01

I’ve been hired by a non-profit organization to develop a WordPress plugin to manage their yearly signup process.
At WordCamp Europe 2013 I’ve picked up Nikolay Bachisky’s suggestion about the book “Growing object oriented software” and am willing to try their approach to TDD.
The first step in development the book proposes is building a walking skeleton: a bare bones structure of the software under development that requires as little design and implementation decisions as possible. I need some requirements to build on and toward and an extended interview with the clients produced a list of requirements like the ones below:

  1. there must be a page to link that allows users to subscribe on their site
  2. the subscription process should allow for at least three types of subscriptors to subscribe (adult, children and supporters)
  3. […]

Requirements fully rest in the client word domain: as far as common knowledge about a website goes there is nothing in the above list requiring deep knowledge of the implementation details. I ended up with a list of 10 requirements born out of their initial needs, my questions about both users and site curators and their answers to the question “what are you trying to improve?”. From requirements I move to outcomes like:

  1. the plugin allows site administrator a to use a shortcode to make the subscription forms appear on a page: in this generic form it shows all subscription options
  2. the plugin allows the site administrator to pre-select which kind of subscription options to show using the shortcode
  3. the plugin allows already subscribed users to review submitted informations when visiting any subscription page
  4. the plugin template to show all subscription options in the frontend must selectively hide the others
  5. the plugin must not allow a user to review her subscription type
  6. the plugin must redirect subscribers of the specified type to a page alternative to the admin one
  7. […]

And so on. The goal of this first step is to move from client domain to development domain and give me the highest possible level of outcomes I will test my code against using Selenium. Any one of these outcomes will be an “end” of an “end to end” test letting me have an handle on my overall progress and giving me a solid “definition of done.”.
I will try to chronicle the build process of this plugin in the post series as there seem to be very little hands-on real-world articles and posts about TDD in a Wordpress environment and hope to share at least my errors if not my knowledge in the matter.