test objects design

Scott Hanselman’s Computer Zen - Sandcastle - Microsoft CTP of a Help CHM file generator on the tails of the death of NDoc

This Open Source stuff is free. But it’s free like a puppy. It takes years of care and feeding. You don’t get to criticise a free puppy that you bring in to your home.

Merging conflicts by hand can be quite intimidating the first time you attempt it, but with a little practice, it can become as easy as falling off a bike.

from svnbook

(msdn examples criteria,expression values)

Field 	Expression 	Description
Date 	Between #1/5/95# And #1/10/95# 	Uses the Between...And operator
Date 	#2/2/95# where valu is 2-Feb-95.
Country 	In("Canada", "UK") 	Uses the In operator to display orders shipped to Canada or the UK.
ShipCountry 	Not "USA" 	Uses the Not operator to display orders shipped to countries other than the USA.
ShipName 	Like "S*" 	Orders shipped to customers whose name starts with the letter S.
CompanyName 	>="N" 	Displays orders shipped to companies whose name starts with the letters N through Z.
OrderID 	Right([OrderID], 2)=”99″ 	Uses the Right function to display orders with OrderID values ending in 99.
CompanyName 	Len([CompanyName])
 />Val(30) 	Uses the Len and Val functions to display orders for companies whose name is more than 30 characters long.

Is Null
Is Not Null
“Value”
“Value” or “Others”
Not “Value”
“” zero lenght string value.
Like “beginswith*”
Like “*endswith”
Like “[A-D]*” Begins with A, B, C or D
Like “*middlestring*”
Like “strin?” last letter unknown

Ruby Sig: How To Design A Domain Specific Language - Google Video: This is David Pollak’s presentation. I didn’t listen to the whole thing but I would love to see the slides just go through them. The most important thought from me is about interveiwing users and writing pseudo code. This is definitely what FUNTOM is about for Test Development.

InfoQ: Domain Driven Design Quickly (download the book)

So we start with the domain. Then what? A domain is something of this world. It cannot just be taken and poured over the keyboard into the computer to become code. We need to create an abstraction of the domain. (…) a blueprint in our minds. In the beginning, the blueprint is always incomplete. But in time, while working on it, we make it better, and it becomes more and more clear to us. What is this abstraction? It is a model, a model of the domain. According to Eric Evans, a domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence. The model is our internal representation of the target domain, and it is very necessary throughout the design and the development process. During the design process we remember and make lots of references to the model. The world around us is way too much for our heads to handle. Even a specific domain could be more than a human mind can handle at one time. We need to organize information, to systematize it, to divide it up in smaller pieces, to group those pieces into logical modules, and take one at a time and deal with it.

Picture is worth a thousand words, no?

InfoQ: Book Excerpt and Review: Applying Domain-Driven Design and Patterns with Examples in C# and .NET

Each requirement is first discussed with a combination of written discussion, hand-drawn UML sketch, and a test case expressed as code. Nilsson uses the hand-drawn sketches to emphasize that the test code is “the most important representation of the real model.” The UML is essentially a stepping stone to the real design documentation and not an artifact in and of itself. The author suggests that a basic UI should be examined early in the design phase. In this way the domain design can be tested against its planned use. As the focus is on the domain itself, very little time is spent on the UI itself, which can be sketched out with pencil and paper.

This quote is useful how? - test code is the most important representation of the real model…

DanNorth.net » Introducing Behaviour-Driven Development

It creates a “world,” which is just somewhere to store your objects, and passes it to each of the givens in turn so they can populate the world with known state. JBehave then tells the event to “occur in” the world, which carries out the actual behaviour of the scenario. Finally it passes control to any outcomes we have defined for the story.

The above quote gives some food for thought. Let me extrapolate: if software development is a game of invention and communication then perhaps we could Model the Gameboard, model the context of the pieces on the gameboard and model the invented moves that can ‘occur’ in such and such a particular state of the game. Perhaps game moves then are the behaviour that can be afforded to occur in that context. Moves in context realize UseCase scenarios. Outcomes are results of the moves where Gameboard is affected and new moves are afforded.
Part of my thinking about FUNTOM is this way. Modeling Functional Test by creating Object Model. My Object Model is the pieces of the game. Functional Test is a set of moves in a context. Bugs are found in this exploratory testing kind of way and regression tests are created to guard against future illegal moves (bugs).
I have a quick example: Recently on a project I needed to test results set pagination. Let’s use Google pagination. At the bottom of a Google results page you have a functionality to access pages of results. Google displays pages 1 to 10 each a link to a corresonding page. Then next and previous links to move to next and previous what? Page. This is important because as I will explain was my problem with pagination. But for now back to distinguishing the way Google does it. So, each ‘o’ in Gooooooooogle is a page. The first “Go” is page 1, then each “o” is a page and the last page is “ogle” or so it seems. - Well the last is 10 if you are on page 1 but then if you move to page 2 the last page is now 11. So a new page is revealed that wasn’t there before. Ultimately Google doesn’t tell you how many pages of results there are in your set. It just tells you the page you are on and allows you to click on each page of the next 9 pages. The most it will ever show you are 19 pages of results which we can call a span or range. The range display behaviour is such: the page you are currently on (as long as it is page 10 or greater) is centered in a range and then there are 9 pages before the page you are on and 9 after. Total 19
What I am actually doing here is modeling the Test Object and its behaviour and since I’ve had a similar pagination to test for a customer this example for Google is pretty interesting to me and allows me to demonstrate FUNTOM implementation. The problem was that the results set was always less than 10 pages and rarely 2 and rarely over 20 and I had two extra behaviors that Google doesn’t show in it’s results pagination
So I started with modeling the world, my world of objects in FUNTOM…. draft. TODO: finish this with screenshots and modeling code

Domain-Driven Design: What Is It?

Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, teams need an extensive set of design practices, techniques and principles. Refining and applying these techniques will be the subject of discussion for this site, generally starting from the language of patterns layed out in Domain-Driven Design, by Eric Evans.

The above quote is a departure point to speak about static versus dynamic view of software requirments and tests. In my experience most business requirements I see are static snapshots, however software has a dynamic behaviour.
Most requirement documents are written in a linear descriptive language but user interaction with software doesn’t work at that level of linearism most of the time. It’s more like a non linear generative behaviour. Most methodologies describe test case creation as step by step instructions that model process but most testers (exploratory tesers) find bugs when they model objects and set up states and move from state to state and trap illogical integration holes that were never thought out.

By modeling requirements you can find conflicts and contradictions and big gaping holes because you model approaches, interfaces, existence, movement, relationships and stuff that you could never do in a step by step linear test execution. As the saying goes “A picture is worth a thousand words” so in requirements and use case scenarios a model or a set of models is worth at least 30 pages of linear descriptive step by step English language statements that most people will not have time to read - and most will not comprehend… and worst of all - a lot of programmers will not use to derive the behaviour of the system because for many English is a second language.

The properly structured ‘the system shall’ statements approach to requirements is a very very costly way to develop software. That language must exist on many projects because of regulatory and contractual commitments but a Domains Specific vocabulary ought to be derived that is behaviour specific and maps to business rules

Many times requirements are divided structurally into units however software works at the level of behaviour, interaction. The organizing structural principle is collboration, interaction and not structure as a collection of units standing next to each other. With that kind of static view of units next to each other Integration becomes very costly and occurs too late in projects. Dave Astels writes “We shouldn’t be thinking about units… we should be thinking about facets of behaviour”. Of course he was talking about context of an object and testing not just a method but specific behaviour in a specific context no matter if it’s a method of one object or many objects collaborating; So maybe we should be thinking of this not as Functional Test Design but Aspect Test Design. Another sense of this is: Aspect is holographic, Functional is linear. With Aspect you switch context or you reside in context from which you see test. You can switch context and reside in a new place from which you see a different family of tests - can you automate such testing? Sure you can. But the automation at this level is not a step by step execution of tests against an application using WinRunner or Watir or whatever automated test tool you have. I think it’s too early. First you automate your context creation by generating activity diagrams. You automate by modeling objects and describing their behaviours.

You distinguish software. you don’t describe it. You distinguish test cases, you don’t describe them. Thoughts?

AcceptanceCriteria - Behaviour-Driven Development

A Tester works with the Customer and an Analyst to define AcceptanceCriteria. AcceptanceCriteria specify, as a collection of Scenarios, what needs to be achieved if the Behaviour of the Feature is to be considered finished.

Test Development is often overlooked on projects. Sadly Test is an activity to find defects after developer has finished coding them. Were it to be more of an activity of scenario building, reviews, walkthroughs, it would be about waste prevention

From Develop Information Architecture

A wireframe is an abstract diagram illustrating the structural aspects of a page or page template. An explanation of how a section of the page may be used or the rationale for the page structure may complement the wireframe. A wireframe defines the types of information and services (including navigation) available on a page.

My FUNTOM notes:

UseCase Model for TestScope.
Activity Diagram to model usecase
Wireframe (maybe I should call them TestFrame or TestWireframe) to model page where TestObjects play the game. I guess test case execution happens in Frames. You move from Frame to Frame. on each Frame there are test objects to send messages to.

in Ruby

module TestFrame
  class GoogleHomePage
    def self.search
      #put watir implementation here of clicking on the button.
    end
  end
end

#example of TestCase step
TestFrame::GoogleHomePage.search

##
# better solution maybe create light framework. Abstract UI
# TestFrame is now some Wireframe object which can be a page
# or a panel or some grouping that we arrrive at and can exit from.
class TestFrame
end

class Google < TestFrame
end

##
# testcase step
Google.search

This way implementation is in inheritance and not in TestCase step notation.