Chapter 1 - Keeping It Simple

At the time of writing this chapter is available free: grab it (PDF) and share your opinion here!

Have you started your meme map yet? For more info on meme maps see (We explain why we need them in Chapter 1).

Show yours here!

Anonymous role?

When you make a list of all the Literary Workshop "roles", shouldn´t be added the anonymous role?
Maybe it shouldn´t because there will always be an anonymous visitor, but then again, the client should tell the developer what should exactly anonymous visitors get access to...

For many sites the anonymous user is the most important

But the literary workshop is a "closed world", a very specialized social networking site where privacy is everything, and membership is by invitation only.

The criteria for whether or not to include a role is, precisely, whether or not there are going to be any user stories for that role: whether that role will be having any significant interaction of value with the system that we need to worry about (i.e., that is in scope).

The big question you are asking here is, is that really zero? Well... I guess we have to ask Pam :)

"Getting your site done right’’ meaning

I found reading this introductory chapter quite interesting, i'm willing to jump right into next chapters as soon as I get my own copy ... working through a real application using the tools & principles described here is big plus!.

Having you said: getting your site done right means that all the acceptance tests pass for all user stories really caught my attention, being my impression that for Drupal projects, more often that not, user acceptance tests are conducted manually by end users.
Using PHP SimpleTest or Selenium has so far been an afterthought in the Drupal community (D7 being to me the first major release having a set of tests at all, please correct me if I'm wrong)... having a process with continuous build sounds promising to me.

Simpletest as unit test all the rage in the Drupal community

First of all thanks for your feedback!

I look forward to your comments as you work your way through the book.

Now, let's first distinguish between unit tests and functional tests.

Simpletest, as unit test, has been all the rage in the Drupal community. Cries for more complete "coverage" (of code) has led to more and more modules including simpletest tests and has, I am sure, led to an increase in quality.

Drupal 7 is being developed with unit tests incorporated into commits.

The problem is that unit tests (associated with code, present to make sure nothing is broken, automated so that they can be run in the future when other new stuff is brought in, that is, used as regression tests) should be a given. They do nothing, nothing, to test whether or not the site developed is the site desired by the client.

For that we must insist on functional tests, or "black box" testing in the development of website applications.

This is never the focus with coders, but must be the focus if the overall product is to be compared to the set of requirements which gave birth to it.

These acceptance tests, written by the client with help from the developer (of each user story, as it is about to be implemented) and executed by the client (with much prodding from the developer if necessary) are indeed the criteria for work being done, for "getting your site done right".

Again, thanks for your feedback,

Victor Kane

Unit tests?

Hi Victor, thanks for your reply!

Ok, so the important thing is Acceptance Tests, executed by the end user, constitutes the criteria by which our work will be judged. Client must have built them, each must map a user story, and must be executed successfully to consider a piece of work done.... being it a manual or an automated process is somewhat accessory.

It is still not evident to me that Drupal tests are indeed unit tests, at least not in the same way that you use them in Java or RoR... they´re more like functional tests, taken place at the UI level: login user, do that, then do something else, assert some text.
What would continuos build be in the case of a Drupal project?

Our focus here is developing sites, not developing Drupal

I think that is what we are trying to define.

Drupal core and contributed modules can and should have unit tests capable of being automated (so that they serve as regression tests, for example, when someone complains about conflict with a shiny new module, the same test can easily be run again to see if a fail occurs where before there was a pass).

This, as I say, should be a given.

But in a website application, any code we write, or heavy PHP theming should of course have unit tests. But when we sit down to implement a user story, the first thing we should do is write an acceptance test for that user story. This can be done with the help of developers, but the "we" should include the client or someone representing her. Then the client executes the acceptance test and the user story is accepted (happy story thread).

So, there are all kinds of "Drupal" tests, but we are focusing here on website applicataions and there, above and beyond the unit test which these days form part and parcel of "coding", the acceptance test constitutes criteria for ... acceptance.