test objects design

In the spirit of continuing my FUNTOM research material here are some quotes I will use for presentations. (bold is mine to highlight concepts)
From An introduction to Model Driven Architecture

Models provide abstractions of a physical system that allow engineers to reason about that system by ignoring extraneous details while focusing on relevant ones. All forms of engineering rely on models to understand complex, real-world systems. Models are used in many ways: to predict system qualities, reason about specific properties when aspects of the system are changed, and communicate key system characteristics to various stakeholders. The models may be developed as a precursor to implementing the physical system, or they may be derived from an existing system or a system in development as an aid to understanding its behavior.Because many aspects of a system might be of interest, you can use various modeling concepts and notations to highlight one or more particular perspectives, or views, of that system, depending on what is relevant at any point in time. (..) how enterprise application developers take advantage of modeling. (…) The UML allows development teams to
capture a variety of important characteristics of a system in corresponding models. Transformations among these models are primarily manual. UML modeling tools typically support requirements traceability and dependency relationships
among modeling elements, with supporting documents and complementary consulting offerings providing best practice guidance on how to maintain synchronized models as part of a large-scale development effort.

(…)

Today, a majority of software developers still take a code-only approach (left end of the modeling spectrum, Figure 1) and do not use separately defined models at all. They rely almost entirely on the code they write… Any “modeling” they do is in the form of programming abstractions embedded in the code…

Any separate modeling of architectural designs is informal and intuitive, and lives on whiteboards, in PowerPoint slides, or in the developers’ heads. While this approach may be adequate for individuals and very small teams, it makes it difficult to understand key characteristics of the system among the of the implementation of the business logic. Furthermore, it becomes much more difficult to manage the evolution of these solutions as their scale and complexity increases, as the system evolves over time, or when the original members of the design team are not directly accessible to the team maintaining the system.

An improvement is to provide code visualizations in some appropriate modeling notation.

The question a Tester would ask here is: where do I get the knowledge of what to test? If I haven’t been to the meetings and haven’t taken pictures of drawings on whiteboards and if I don’t possess magic that would allow me to enter developer’s heads and rummage around..? what then? How do I test the system? how do I manage coverage, acceptance criteria? - Perhaps an improvement is to model it not on develpment side but on Test site. Develop TestObject Model, a view, a perspective that highlights Testability of the system. This approach I call FUNTOM. Functional Test Object Model. The key to is not code visualization but functional requirements visualization, behaviour visualization, collaboration of Test Objects visualization.

A model-only approach is at the far-right end of the coding/modeling spectrum shown in Figure 1. In this approach developers use models purely as aids to understanding the business or solution domain, or for analyzing the
architecture of a proposed solution. Models are frequently used as the basis for discussion, communication, and analysis among teams within a single organization, or across multi-organizational projects. These models frequently appear in proposals for new work, or adorn the walls of offices and cubes in software labs as a way to promote understanding of some complex domain of interest, and to establish a shared vocabulary and set of concepts among disparate teams. In practice, the implementation of a system … may be disconnected from the models. An interesting example of this is the growing number of organizations that outsource implementation and maintenance of their systems while maintaining control of the overall enterprise architecture.

We have seen a number of fundamental shifts in the way software practitioners perceive software-intensive solutions. These moves have changed the mindset of the vast majority of software engineers. Formerly, they concerned themselves
with the low-level details of manipulating bits of data and moving bytes between registers in the CPU; now, increasingly they spend a majority of their time understanding the users’ problem domain in terms of use cases to be supported, and designing solutions that they conceptualize as collaborations of services offering behavior to realize those use cases. This profound shift in thinking has only been possible because it has been supported by effective tools that allow the new concepts to be clearly expressed and shared.

(…) organizations are well-served by creating models of the problem domain and solution domain, and by coordinating these models throughout the life of a software project

So I am strongly recommending that software projects utilize TestObject Model by modeling UseCases behaviour with Activity diagrams. I would use Wireframes instead fo actuall UI screenshots. Wireframes as conceptual schema. TestObjects modeling logical entities in a UseCase and not physical models in a system.

Here is a quick example:
When you send email you can model TestObject EmailMessage. In it you specify attributes like address, body, subject and actions like send, save, discard. All of those messages (I like to use messages instead of methods) change this TestObject state. A zcode (zcode == pseudo-code) could be like this:

## 
# TestObject skeleton
class EmailMessage
  attr :address
  attr :subject
  attr :body

  def send
    #wire behaviour for sending message
  end

end

# TestCase steps as zcode

EmailMessage.address = "president@mycorporation.com"
EmailMessage.subject = "Please Implement FunTom"
EmailMessage.body = "It can save you a ton of money"

# finally behaviour can be like this:
EmailMessage.send

##
# We are not concerned with wiring the messages with code 
# that actually does something. We are modeling behaviour of TestObjects
# So now we can have some test conditions

if @address != :address
if @subject == nil
if @body == nil

# There are 3 TestConditions to explore. 
# Each one of the conditions tests some expectations.

#In Rspec we can do this even better.
require "rspec"

##
# rspec scaffold
# writing specificaitons of a TestObject
context "marekj sends an email message" do
  specify ":address must entered" do end
  specify ":subject should not be empty" do end
  specify ":body should not be empty" do end
end

# we can leave TestObject static and write TestObject specs with rspec
# TestObject can be wired with Watir later for execution