How do you plan your Rails app?

Question

I'm starting a Rails app for a customer and am considering either creating a mind map or jumping straight to a Cucumber specification.

How do you plan your Rails app?

As an additional question, say you also start with Cucumber, at which point would you write Unit tests? Before satisfying the specifications?

Winchester

I think this should be community wiki. – Sag

Answer 1

I've got a 6 step process.

1. I prefer to work out the model relationship and uses before doing anything. Generally I try to define models into units containing coherent chunks of information. Usually this starts by identifying the orthogonal resources my application will need (Users, Posts, etc). I then figure out what information each of those resources absolutely need (attributes) and may potentially need (associations), and how that information will likely be operated on (methods), from there I define a set of rules to govern resource consistency (validations).

   I usually iterate over my design a few times because the act of defining other models usually makes me rethink ones I've already done. Once I have a model design I like, I will start refactoring or specializing(subclassing) models to clarify the design.

2. I write the migration and make skeletons for my models. I usually won't write tests until I have a first draft of methods and validations implemented. It's not always obvious how to implement things until giving it some moderate thought.

3. Next comes the test suite. Doesn't matter what I used to write the tests, so long as I can be certain the backend is sane.

4. This is when I piece together the control flow. What happens on a successful request? Unsuccessful request? Which controller actions will link to others? Usually there is a 1-1 mapping between controllers and models (not counting sub classes of models), every so often I'll encounter situations where I need to act on multiple model types, for that I'll probably create a new controller. Depending on how complex my app is I may model the flow as a state machine.

5. Lastly I create the views. I start by sketching out the UI based which is heavily influenced by my model's relationships and attributes. Abstract out common parts, then write the views.

6. Polish the UI. I create a CSS, and start to replace links with remote calls, or even just javascript when appropriate.

I may interleave steps 2 and 3. I find it's very easy to write a test just after I write the code to be tested. Especially because I'm usually testing things in a console as I write, and half the test is written by pasting from the console.

I may also compartmentalize steps 4 and 5 for each model/controller. Any point I may go back and revise, a previous decision, and propagate those changes through my steps.

Libby

You don't say how you identify the models and controllers. – Moraine

I kind of glossed over that. I felt that description was too in depth for such a vague question. I've edited to include it now. While I was at it I added similar detail to my other steps, and even added one. – Libby

Answer 2

I start with sketches of the user interface and then progress to HTML mockups. Once the UI design is finalised I can identify the RESTful resources in the application and their relationships.

Moraine

Hi John, Can't you identify RESTful resources by carefully mapping the Domain? – Winchester

You could do, but starting with the UI first helps me identify where the domain boundaries are. See gettingreal.37signals.com/ch06_From_Idea_to_Implementation.php – Moraine

Answer 3

I don't think writing only cucumber features as specifications is a good idea. Writing test code without be able to test it pass leads to errors in the tests and increases the time you'll need to correct them later.

So I'd do the following :

• Write some mindmap. But keep it simple with the major ideas of the project.
• Start writing tests and coding at the sime time (write one test, make it pass, write an other, ...).

So you'll write your specifications while driving your application. Keeping it clean but also remaining agile and being able to change some ideas in the middle of the project.

Sag

No. As long as you allow yourself to change what you've defined before when the project evolves, you remain agile. – Sag

I was thinking of writing the Features early to be able to identify what Model methods are need, then writing the Unit tests, then going back to getting the Features to pass. – Winchester