+972 52-548-6969
Business Oriented Testing: FIT vs. DSL
time to read 1 min | 189 words
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 )
Comments
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.
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.
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?
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.
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
Ayende,
See my thoughts here; it got too long for a comment.
http://hrboyceiii.blogspot.com/2007/08/fitting-acceptance-tests-with-dsls.html
Comment preview