DeclarativeTestInfected

After creating the proposal below, I've realized that we should probably submit instead

What we are trying to accomplish
An example of procedural vs. declarative tests
How we will accomplish what we want to accomplish

I also see that Mike Hill has submitted a very similar proposal http://submissions.agile2008.org/node/1753 (His "Copy and Paste Workflow" is the same as our "Declarative vs Procedural") This may not matter; we're submitting to a different stage, anyway.

But keeping in mind the stage's Call for Participation: "Clinics provide on-demand training and support in a specific skill" and "submit a proposal for a three-hour “workshop” and indicate which clinic you are interested in. Please discuss the type of hands-on exercise(s) you have in mind for the clinic and how you would structure the time."

What do we want to accomplish? Perhaps, we want them to come away with an understanding of the benefits of declarative tests.

Declarative tests are understandable (less noisy)
Declarative tests help us think of more test cases
Declarative tests are robust (less fragile)
Declarative tests are easier to write "up-front"

Idea: Should we explicity try to teach FitNesse? That might add value to some folks who are looking to the Acceptance Test Jam as a way to help them get started writing automated tests.

Idea: How about starting by showing the whole class various examples of tests, one at a time, and having them rate each example for understandability? Then we could roll up everyone's ratings and see which tests "win". Similar to a session I very much enjoyed at Agile 2007 http://www.agile2007.org/index.php?page=sub/&id=816

Concern: It might be difficult to show that declarative tests help us think of more test cases. Was this the basis of our idea of "competing" to "see which tests find more bugs"? I'm not sure counting bugs discovered is a good approach. If I really wanted to find the most bugs in the shortest amount of time, I would test manually...

Idea: They could practice "refactoring" procedural tests into declarative tests. (um, very similar to Mike Hill's exercise.) This is a good way to show how declarative testing is really removing duplication in your tests. Perhaps this could include a discussion of the dangers of refactoring tests. (When you write a new test, you usually see it fail before it passes. When you "refactor" you might skip this step. If you don't ever see the test fail, how do you know it's really testing something?)

Idea: Have a section about creating declarative style tests when you're testing through the GUI. (Because some people say this can't be done, but it really isn't any different. Just a matter of abstracting the "click, click" parts of your tests.)

Idea: Can we show that declarative tests are less fragile? Can we pitch them a requirements change and have them experience the "joy" of changing the tests in response?

Idea: Do we "expand" into giving examples of creating test objectives from requirements? Procedural tests is such a widespread "test smell" (yuck) and often the reason is jumping into automating a test before we have a test objective. (This might tie into the objective of "Declarative tests help us think of more test cases.")

Idea: I like this quote by Rick Mugrige: "Develop a test language that best describes what's important to you."

I've been watching how the Developer Jam proposals are being reviewed. Here is one that is reviewed as "perfect" for the Automated Testing developer jam: http://submissions.agile2008.org/node/446

This one was reviewed as "might be on the wrong stage" because it encourages pairing a business person with a developer/tester. The stage owner said "If the intended audience is more than just developers perhaps another stage would be a better fit?" http://submissions.agile2008.org/node/425

The only other automated testing clinic submission so far is a moderately-well-reviewed one on Fitnesse.NET: http://submissions.agile2008.org/node/734

We wish to submit a 3 hour "clinic" proposal to the "Developer Jam" (http://www.agile2008.org/stage-developers.html) stage of Agile 2008, specifically to address their Call for Participation in their words:

"We have a big need for experienced 'master programmers' to run the various clinics, in half-day (3 hour) time slots. We have potentially eight such slots for each clinic. While each session in a clinic will cover the same basic skill, different slots can have a slightly different focus. For example, the TDD clinic may have a ruby exercise in the morning, and a Java/J2EE exercise in the afternoon on one day."

The organizers plan to run four clinics:

Test-Driven Development
Continuous Integration
Clean Code
Automated Testing

We will be submitting this proposal to the Automated Testing clinic.

Other session ideas we considered:

Testing using DSLs
Storytest driven development
Building keywords out of keywords
Testing at API level vs. UI level
Anti-patterns of automated testing
Non-functional testing
Unit testing - Hard things to unit test

We settled on "Becoming Declarative Test Infected"

Still need to figure out exercises, the applications under test, the test tool(s) we want to use.

Notes, ideas, sound bites:

"Tests with a purpose"
Simplify
Declarative in the real world
Write one imperative, then switch to declarative for the test cases
3 levels of depth into the application = 3 levels of abstraction in the tests
Even when we think about test cases, we still easily get pulled too far into the details of the steps/tools/code.
Tools don't matter; steps don't matter; test objectives matter.
Coolness factor for exercises (e.g. robots are cooler than banking applications)

Declarative Test Infected

Abstract

Describe declarative vs. imperative, briefly describe the clinic, some kind of hook to get interest.

Objectives (What will people get out of this session?)

Stronger, more diverse tests
Easier to write up-front
Strengthen your declarative point of view
Focus on verification

Audience

Probably developers and testers. Should we encourage other folks to come? which folks?
Bring laptop set up with Java programming environment

Structure/Process

(10) Introduction - Describe session.
(10) Group brainstorm test cases for a sample application.
(15) Warmup exercise (We will provide the applications under test, and most of the test code, and they just complete it)
- Complete one declarative test on Application A.
- Complete one imperative test on Application B.
(30) Exercise (More in depth now. We will provide the applications, with a fair number of bugs that we have injected)
- Complete more imperative tests on Application A.
- Complete more declarative tests on Application B.
(15) Debrief - Comparison - How many bugs did you find? Did one approach find more bugs? Pros and cons?
(10) Wrapup and teaser for the next session - Perhaps we will run a declarative test we have created, covering the test cases they brainstormed at the beginning. Describe the competition that will happen after the break.

<Break>

(15) Show a few good examples of declarative tests (Good habits/patterns)
(45) Exercise (Somewhat more realistic testing situation. Competition - Teams write automated tests to demonstrate bugs in the application.)
(15) Results of competition - Award prizes for:
- Number of failing tests (bugs found?)
- Readability of tests (Judge?)
(15) Final debrief (pros and cons of each approach) and participants share their a-has.

Hand out "I am declarative" buttons at some point...