JavaScriptMVC

JavaScriptMVC Framework JavaScriptMVC

Gojko Adzic » The principle of symmetric change

說明開spec的一些注意事項，裡面提到 spec 應強調 what，而非 how.

Gojko Adzic » The principle of symmetric change

The principle of symmetric change

Published by gojko at 12:29 pm under articles

One of the most important lessons that I’ve learned as the result of the research conducted for my upcoming book Specification by Example is that many of the most common problems people have with implementing BDD or agile acceptance testing come from a misalignment of conceptual models. By changing our view at the specifications/tests we can make most of those issues go away instantly.

The most useful software models are the ones where the technical view of the world is aligned with the relevant business domain model. This ensures that one small change in the business domain (new requirements or changes to existing features) results in one small change in software. This is one of the key ideas of Domain Driven Design. The alignment of the technical and the business models ensures that software evolves nicely with the business and that we never get into a position where a small report change requires a rewrite of the entire system or six months to implement.

The same is true for the other artefacts produced for software — especially tests and documentation. When the conceptual model used in the tests is aligned with the business domain model, one small change in business will result in one small change in tests, making the tests easy to maintain. This applies to the language used in the tests, the abstractions used to describe features and the way that the tests are organised. So I propose the following principle to get good executable specifications/acceptance tests/bdd scenarios/feature files/fitnesse pages or whatever you call them:

The principle of symmetric change
One small change in a business model should require one small change to executable specifications.

To achieve this, ensure that:

• each specification should be focused on a single concept of the business domain model (which might be a business rule, step in a flow, or something higher such as the overall definition of a business process)
• the concepts used in key examples in a specification are closely aligned with the business domain model and reflected in underlying software domain model. this includes naming (concepts are described in the business domain language) but also the relationships between them.
• the (automated) validation procedure is clearly separated from the specification of key examples
• the specifications are organised into a living documentation system according to the conceptual relationships that exist in the business domain model

Thinking about aligning key examples and specifications with the business domain model instantly solves many of classic acceptance testing/bdd problems we identified during a CITCON workshop in Paris last year. For example, “Focusing on How, not What” is a sure way to write tests that are very hard to maintain (非常認同，太過執著枝尾末節的how容易失焦)but lots of teams still do it. By thinking about aligning the language and abstraction concepts in the specifications with the business domain model, we force ourselves to describe what the software should do, not how it does it. This separates the specification (what) from the validation procedure (how can we check it in software). The validation procedure can then be automated using a tool. This is a classic problem that Ward Cunningham and Rick Mugridge have identified in Fit For Developing Software nand advised readers not to automate flows. But that is an overly generalised statement – it confuses people who deal with genuine workflows, for example in payment systems where business workflows are everything. David Peterson advised people to focus on specification over scripting, which is less generalised but still not directly to the point. Flows or scripts aren’t the real problem – it is mixing the business definition of a function with the validation procedure.
將精神放在 flow 或script，容易讓我們看不清真正的問題，就跟我們在srs中表達「系統的細部功能」時，容易看不出企業真正想解決的問題，只看到最後的solution，但這solution是否有命中客戶想解的問題就不得而知。

Thinking about specifications and tests in this way also prevents people from falling into the trap ofThe Sine of Death by UI Test Automation. Tests described with low level technical detail, in the language of technical UI interactions, are everything but aligned with a business model. If anything, they are aligned with the current design and layout of user interfaces. A small change in business requirements can have a huge impact on such tests, requiring hours of updates to tests after just a few minutes of changes to the code, which then fails the symmetric change principle.
這段正是最近幾年開spec的心得， 當你寫得越細時，稍有異動就會改死，實際上一些細部solution應在code的層級發揮，而不應在 spec 中討論，盡量讓spec保持一定程度的抽象化，所以如果在我眼中，若在spec中看到 psuedo code，算是不及格的spec。當然有時候psuedo有其必要性，但不應寫在spec中，而是實作指引之類的說明文件。

Ensuring that the specifications are aligned with the business model and in the business language, organised according to the relationships the underlying concepts have in the business model solves all the reasons behind the “Tests unusable as live documentation” family of problems, and ensuring that the previous documents are still aligned with the new model resolves most of the issues we described as “Test code not maintained with love”.

Get notified when I post something new - subscribe via RSS or Twitter!

Gojko Adzic » The principle of symmetric change

說明開spec的一些注意事項，裡面提到 spec 應強調 what，而非 how.

Gojko Adzic » The principle of symmetric change

天下雜誌 - 到底是「將」? 還是「士」! CEO部落格

天下雜誌 - 到底是「將」? 還是「士」! CEO部落格

DB2 connection is so difficult to build !!