Business Oriented Testing: FIT vs. DSL

Jeremy Miller is talking about getting disillusioned about FIT, and I have to agree. FIT is a good idea, but the implementation leaves a lot to be desired. For myself, I am very interested in the ability to express the requirements in a way that is clear, concise and can hopefully make sense to a business user.

Instead of going with the FIT route, I think that I would go with a DSL for testing the domain. For instance, let us say that I want to test scheduling work for employees.

Something like this:

emp = Employee("Smith", Qualifications: [ Medic, Doctor ] )
requirement = Requirement(For: Medic)
assert requirement.MatchedBy(emp)

Now, this looks a lot a unit test, right, but the advantage here is with the bigger scenarios, this mainly simplify ObjectMother scenarios, but it can make the test a lot easier to figure out.

doc = Employee("Smith", Qualifcations: [Medic, Doctor] )
driver = Employee("Joe", Qualifications: [Driver, Medic] )

cannot_work_together doc, driver, "Had a fight"

shift = Shift("Morning")
task = shift.Tasks.Add("Ambulance")
task.AddRequirement( Requirements.Doctor )
task.AddRequirement( Requirements.Driver )

shift.Add( doc )

assert_would_fail shift.Add( driver )

assert_false shift.CanBeSatisfiedBy( driver )

Print | posted on Monday, August 13, 2007 12:55 AM

Feedback


Gravatar

# re: Business Oriented Testing: FIT vs. DSL 8/13/2007 9:44 AM Håkan Forss

I agree that DSL could be the way to go but the DSL has to be less code oriented otherwise the customers will not be able to participate in the writing of the requirements and running the tests.

FIT may have a poor implementation but the concept is sound in my way of seeing it.


Gravatar

# re: Business Oriented Testing: FIT vs. DSL 8/13/2007 10:19 AM Gil Zilberfeld

I agree. One of the attractive features of FIT is the ability for non-programmers to write the tests. The table metaphors worked well with people I described the tool to.

DSL and fluent interface could be a step in the right (Although other) direction, but the simplicity for non-programmer maybe lost. I'd like to keep that.

As a programmer, I do like the syntax here.


Gravatar

# re: Business Oriented Testing: FIT vs. DSL 8/13/2007 10:47 AM Frans Bouma

You all think like programmers, but the business analist doesn't think like a programmer. Using a non-ambiguistic DSL with strict syntax won't work, as these people don't think in programming languages and syntaxis. So they need a language which allows them to formulate the same thing in a variety of ways, and it should be flexible and tolerant in syntax checking. Otherwise the business analist is spending a lot of time fighting errors in the specification formulation.

For the people who think I'm crazy: think back to the days when you had to write your papers in LaTex or nroff and you had to compile (!) your documents and had to fix (!) syntax errors. Frustrating, wasn't it?


Gravatar

# re: Business Oriented Testing: FIT vs. DSL 8/13/2007 11:27 AM Ayende Rahien

Frans,
The example above is for a specific scenario, but if I had to build a DSL for a business users to use, I would sit with the analyst and work a syntax with him, in his terms.


Gravatar

# re: Business Oriented Testing: FIT vs. DSL 8/13/2007 8:23 PM Gil Zilberfeld

Frans,

You're not that crazy. However, I use Word, which compiles what I'm writing as I write, fixes mistakes and offers suggestions. So if Word as an IDE works for writers, a similar tool cannot be that far, right?

Gil


Gravatar

# re: Business Oriented Testing: FIT vs. DSL 8/20/2007 7:13 PM Harris

Ayende,

See my thoughts here; it got too long for a comment.
http://hrboyceiii.blogspot.com/2007/08/fitting-acceptance-tests-with-dsls.html

Comments have been closed on this topic.