![]() It takes extra time to understand what's being demonstrated. They take up a lot of space, but much of it is boilerplate. ![]() Second, I've found flow-style examples to be verbose and difficult to understand. I would rather have examples that illustrate the business rule directly. In many cases, they show the effect of some underlying business rule. So why don't I just go with the flow? (heh.) If Fit's unique value is to enhance collaboration, and if business users think in a flow style, what's my problem with flow-style examples?įirst, I think flow-style examples tend to sidle around the essence of the problem. When I ask for an example of their thinking, they tend to answer with, "we do this, then the machine does that, then this happens, etc." In other words, a flow-style example. The automated testing-or, as I prefer to think of it, the automated feedback-is an important part of that value.Īs I've worked with business experts, I've noticed-as I'm sure everyone has-that their default mode of thinking is a flow style. :-) Now that I can take some extra time to phrase my thoughts, I'll explain further.Īs I said at the summit, I think Fit's unique value is its ability to enhance collaboration between business experts and programmers. My call to "test business rules!" at the summit may have been a little strident. The following is lightly-edited copy of an email I sent to the Fit-devl mailing list.Īt the Fit Summit last Friday, I kept beating the same drum over and over: I said that declarative tests using ColumnFixture were a more effective use of Fit than imperative tests using flow-style fixtures like ActionFixture and DoFixture. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |