Just a quick update on the prototype for our agile project. We’ve dramatically improved test coverage, implemented authentication-restriction for some functionality, and refactored a litte of the code. Read on for the latest stats on coverage and testing.
Code and Test Metrics
While code-coverage metrics might be more useful, we don’t know how to calculate them yet. Here’s the same data we used in our previous update.
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers | 140 | 86 | 3 | 16 | 5 | 3 |
| Helpers | 7 | 6 | 0 | 0 | 0 | 0 |
| Models | 77 | 56 | 2 | 9 | 4 | 4 |
| Libraries | 233 | 145 | 3 | 30 | 10 | 2 |
| Components | 0 | 0 | 0 | 0 | 0 | 0 |
| Model specs | 169 | 134 | 0 | 0 | 0 | 0 |
| View specs | 86 | 62 | 0 | 0 | 0 | 0 |
| Controller specs | 74 | 54 | 0 | 0 | 0 | 0 |
| Helper specs | 86 | 62 | 0 | 0 | 0 | 0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 872 | 605 | 8 | 55 | 6 | 9 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 293 Test LOC: 312 Code to Test Ratio: 1:1.1
Two interesting things to note:
- Our test-to-code ratio is now greater than 1. It should be even higher.
- We now have independent testing of the model, controllers, and views. What this means is that we can isolate specific behaviors and test them independently of other parts of the code.
More RSpec Tests
Here is the list of tests that we have written and that have been implemented.
Testing the controllers
When anonymous users interact with articles
- listing the articles should be successful
- showing an article should be successful
- editing an article should redirect to login
- creating a new article should redirect to loginWhen authenticated users interact with articles
– listing the articles should be successful
– showing an article should be successful
– editing an article should be successful
– creating an article should be successfulTesting the User Model
A user with articles
– must be able to find all her articles TBD
Multiple users
– must not have the same login ID
– must not have the same email addressA user, in general,
– must have a login ID
– must have an email address
– must have an email address with a valid format
– must have a password
– must have a long passwordTesting the Article Model
An article
– must have a title
– must have a URL
– must not duplicate an existing article TBD
– must be associated with the user that created it TBDTesting the Rendering (presentation) of Articles
/article/list
– should include the list of articles
– should include the individual article titles
Refactoring
One of the mantras of Rails developers is “DRY” – Don’t Repeat Yourself. And it applies to not writing the same code over and over again. With testing of the rendering (the user interface) of articles in place, I was able to refactor the implementation code to get improved re-use. The process went as follows:
- Write code the first time.
- Write tests, confirm their accuracy.
- Rewrite the rendering code with re-use in mind (because we will list articles in many different ways – most recent, highest rated, etc).
- Notice that the tests are failing.
- Fix the new code until the tests pass.
Step 6 was a quick visual inspection / sanity-check that the UI was behaving as the tests assured – and it was.
Summary
At this stage, the prototype can
- Create/Edit users
- Create, Edit, Update, “Delete†articles
- Enforce the need to login to create an article
The next things to work on (where work = code + test) are
- Associate the article with the user who created it
- Create/Edit ratings (of articles, by users)
- Associate the rating with the user who created it
- Associate the rating with the article to which it applies
- Calculate the article “score†based on ratings
- Add a couple presentations (latest articles, highest scoring articles)
- Add a little styling/layout effort
- Deploy the prototype.
Still planning on getting a prototype version deployed before our second anniversary as a company (Cinco de Mayo). Most of today was spent learning how to test the different elements of the code with RSpec. Tomorrow will have more implementation accomplishments.
Anything missing?
Moving along nicely. It’s probably more consistent with agile to write tests before code, so you might try reversing the order of those two items in your refactoring process.
I realize that we are not very far into the product (it’s the first prototype), but I still think that ratings should be postponed to ‘after comments’. Just for the sake of the priorities which were set by the voting on the use cases.
If you think about the ratings as something more complex to display than an unordered list, something that is more exiting for the prototype users, I suggest to use ‘areas’ for this purpose. Again, because of the primary use cases.
However, what do you think about a first prototype w/o ratings and w/o comments? Suggesting arcticles and browsing areas are the main use cases, so we should first check that. I’m referring to the Eliminate Waste principle of Mary Poppendieck’s Lean Software Development (I see that ratings are not a waste in general, but maybe as of now).
Heh. Just finished the prototype implementation of ratings (you can make them, the article score is the average of all ratings made by users on the article).
I should be able to get categories implemented with a fixed list. Then I need to update the views for (latest, highest scoring) and filtering by category.
I think an article should be able to be in multiple categories.
Thoughts?
1 article in 1..* categories: definitely.
For similar problems, I tend to have fixed lists of categories, as long as there is a way to change the list.
Implemented it. I created six categories to start with:
# Define existing categories
Category.create :name => ‘Product Management’
Category.create :name => ‘Business Analysis’
Category.create :name => ‘Project Management’
Category.create :name => ‘Testing’
Category.create :name => ‘Agile Development’
Category.create :name => ‘Interaction Design’
I think that will get us started. Need to do a little bit of presentation/cleanup, and then deploy the site.