[rspec-users] Cucumber Feature Scenario critique
apremdas at gmail.com
Wed Feb 25 11:29:15 EST 2009
Thanks for taking the time and providing more fodder to chew on.
There are a couple of things I'd like to point out
Modelling the world is a futile and pointless task. Its to big and
complicated. Model YOUR world instead, choose the external boundaries
carefully and make your world as simple and small as you possibly can.
I'd question whether you need to give a monkey's about 'entity'. Whilst it
maybe an essential concept in the overall legal framework that doesn't mean
it has to be in YOUR world. If your software is about recording services
provided to some client and related payments. You can simplify - you can
just choose not to model all that legal stuff. If you model everything
1) Never write anything ... or
2) Create something so complex that nobody will ever be able to use it ...
3) Create something that just won't work
I think the major concept here is 'Account'. You service accounts. Accounts
have clients. Accounts can be dormant or active. Accounts have
dormant_periods (and active_periods). Periods have starts and ends.
Active_Periods have activities some of which are charged. When an account
becomes dormant all incomplete activities are suspended.
The complexity of clients, legal entities etc. doesn't help you get paid. If
you really need to record it consider just using text. Client X is a legal
blah servicing blah with blah blah ... . Humans especially lawyers are real
good at writing and understanding that xxxx. When you can't get paid because
you client modelling is to simplistic then revisit it.
Part of the point of BDD is to only do the things you have to do. To justify
everything you do by proving it has specific business value. I've seen in
some of your feature examples a classic BDD cop out - paraphrasing
Feature: Represent Legal Entities
In Order To: Reduce Costs
In Order To: Increase revenue
In Order To: Add business value
These are wooly justifications and a big BDD smell. With these you can
In Order To: Reduce Costs
I should implement self relationships between clients so they can provide
transport for themselves!!!
If you can't write a precise narrow and valid reason to do a specific
Feature you shouldn't be doing the feature. However finding and expressing
these reasons is one of the hardest things to do in BDD. So its just human
nature to cop out and write a wooly justification - after all we know we
need to do this Feature thats why we are writing it. But fundamental to BDD
is to question every Feature we want to write and only write it if we need
it right now and it gives us value now.
If you take this approach and use BDD from the beggining you will start with
In order to model the relationship between our company and our clients
We need accounts
So we can encapsulate the work we do in a seperate entity from the client
Hopefully the following will help
2009/2/24 James Byrne <lists at ruby-forum.com>
> Andrew Premdas wrote:
> > James,
> > Client is not a good name for an emphemeral role. If you need adverbs
> > and adjectives to clarify your verbs and nouns, then your verbs and nouns
> > aren't good enough. I'm not convinced that Entity is a particularly good
> > name either the fact that you need so many words to specify what it
> > is = bad smell.
> > Now if you use replace Entity with Client, then you have Clients who you
> > represent. Each client has a history. The history consists of 'periods'
> > when you represented them (haven't found a good word for that yet) 'term'
> > might be reasonable but I'm sure there is some proper legal term perhaps
> > related to contract. Anyhow use whatever resources you can and find
> > words if you can or hyphenated words if you really have to
> > Seems I've gone on another 'rant'!
> I do not mind. This is one of those "frank and useful exchange of
> ideas" that I sometimes find myself in the office. There is always
> value in reading an informed opinion.
> My situation is somewhat perverse in that I am converting an existing
> system that really does not need conversion. This system is now some 25
> years old and it is still extensible and flexible enough to meet all of
> the tax and trade regime changes of the past 20 years and foreseeable
> future. We are forced to convert because of a business decision of the
> equipment vendor.
> The choice of terminology is a difficult one for us because in this
> industry many terms in casual business use, like client, have specific
> legal import and attached liabilities. The choice of entity was not an
> easy one to make. It was chosen mainly because all the alternatives we
> could think of were worse.
> You see, the law has this concept of a "legal person", but not all that
> have standing in the courts are legally "persons" (not exactly true,
> there has to be one or more actual legal persons somewhere in the
> background but the idea is close enough). There exist associations
> (such as a partnership) that may conduct business, enter into contract,
> and assume legal and financial responsibility for their actions without
> themselves being a "legal person". This is an issue for us.
> Further, in our industry, it is a commonplace that an entity have
> multiple roles with respect to our firm. A transport company for
> instance may, at the same time, be a "client", a "vendor" and a
> "provider". Each of these roles possess specific legal and financial
> attributes but, it is vitally important that the fact that these are all
> the same legal entity be evident at all times. It is also critical that
> any change of status in one role does not obscure the existence of any
> As it turns out, this is one area our existing system does not do well
> at all. We have separate clients and vendors there and we really have no
> good way of tying them together for the same body. We have virtually no
> way of systematically handling entities that have no financial
> relationship with us. We cannot immediately tell if a current client
> has been with us for 30 years continuously or was with us 30 years ago
> and has recently returned.
> A further complication is that we often deal with multiple incorporated
> bodies of the same international firm. Each of these has legally
> distinct attributes but are nonetheless a single "client" insofar as we
> consider them.
> We have done the CRC thing, and we have had an awful lot (an AWFUL lot)
> of discussion about the meaning of things. The idea of client as role
> evolved out of a great deal of discussion on what a client really was
> (any legally distinct body that issues, or causes to have issued on
> their behalf, instructions to us, that we accept, and that acknowledges
> a financial obligation to us thereby).
> What this comes down to is a simple "service for fee" but, there are a
> vast number of corner cases in international trade. There are whole
> books written on just terms of sale. There are marine insurance issues.
> There are government security and tax agency issues. There are
> international banking and payment issues. There are consumer and
> environmental safety issues. Instructions can be issued on behalf of
> clients by trucking firms, ocean shipping lines, airlines, warehouses,
> consolidators, government bodies (both foreign and domestic) and law
> enforcement agencies.
> It is entirely possible for one of our clients to act as their own
> "provider" (use of company vehicles for international transport).
> Nonetheless, we owe a duty of care to our "client" to ensure that the
> "provider" is properly instructed and authorized to conduct a movement.
> A client may act as their own "supplier" as well (goods can be shipped
> from one division to another of the same firm located in a different
> country). A client may be the "producer" of the goods as well as the
> "supplier", but a third-party logistics management company might be the
> actual "shipper". These are legally distinct, but financially related,
> roles assumed by a single entity or its agents. The distinctions are
> important for us because, when we act for a client we act with power of
> It is confusing. It is so because that is the business and regulatory
> environment created by a myriad of government agencies, financial
> practices, insurance regimes and transportation means.
> And writing this stuff out helps sort out a lot of confusion, at least
> for me.
> Posted via http://www.ruby-forum.com/.
> rspec-users mailing list
> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users