>> This message will be posted in BDD, DDD, XP and RhinoMocks groups. Apologies in advance for the duplication.>> project url: fluentspec.com
Introduction "Name classes and operations to describe their effect and purpose, without reference to the means by which they do what they promise. This relieves the client developer of the need to understand the internals. These names should conform to the UBIQUITOUS LANGUAGE so that team members can quickly infer their meaning. Write a test for a behavior before creating it, to force your thinking into client developer mode." -- Eric Evans There is one main principle behind FluentSpec: simplicity. It automates the test setup, removes the Test Doubles and leaves a minimal footprint on test code. It merges classical and mockist styles of TDD with a BDD mindset. Its ultimate goal would be to help shifting our thinking into client developer mode, enabling the flow of Supple Designs. FluentSpec is a natural evolution in the field of unit testing. It can be described from a mockist standpoint but it is not a prerequisite to possess this knowledge. Mock frameworks have been proven hard to understand by newcomers into the world of TDD. That is one of FluentSpec's strengths; it should feel natural for experienced TDD'ers and easy to grasp by novice minds. The main concern for minds discovering TDD should be to find a comfortable test cycle length. A test cycle is one round of red/green/refactor. The shorter the cycle, the more fluent the process becomes. FluentSpec simplifies that cycle by eliminating all the noise and promoting the three-phased testing pattern of Setup, Exercise and Verify. These phases provide a stable structure for the tests, allowing the developer to put more focus on finding descriptive names. That is where this framework does the magic. It provides a fluent interface with sentences starting from the BDD terms of Given, When and Should. This triggers the flow of the Ubiquitous Language from a client perspective. When these sentences are structured in phases the test becomes a user story that serves as a specification of the SUT's behavior. This leads to code that is easier to understand and modify -- in a word, suppler. Once the story is created, the next step is to go back to green as soon as possible. FluentSpec excels in transparency here. The programmer controls the isolation levels by virtualizing methods and abstracting dependencies. The more we abstract, the less concrete code that needs to be written and the faster we get back to a green state. FluentSpec hides the test double behaviors behind BDD intentions: The SUT is a state-machine that behaves like a Stub on Given, a Spy on When and a Mock on Should. Every test cycle ends with a refactor following the DRY principle. Since the story was written with a fluent interface, the refactor can be easily driven with automated tools. This is a natural feature in most mock frameworks. However, FluentSpec makes it simpler by making the methods and properties of the SUT part of the method chain instead of arguments with delegates and closures. BDD is a particular strategy of TDD that catalyzes the distillation of the Domain by setting up a conversation about the SUT from a client's perspective. Since clients don't care about the hows, implementation details are removed from interfaces and the code becomes simpler to understand. As a side effect it also becomes more encapsulated and easier to change. These are the fundamental characteristics of Supple Designs. FluentSpec wishes to lend a helping hand on their discovery. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/RhinoMocks?hl=en -~----------~----~----~----~------~----~------~--~---
