External Behavior and Internal Behavior in Different Domains
In a previous article https://www.dhirubhai.net/pulse/external-behavior-internal-triad-ken-pugh/ I outlined my approach to behavior for a software application.???To recap, the diagram below shows an application represented by the large circle.??There is external behavior which is visible to a customer (e.g., a user or a stakeholder) and internal behavior that creates that external behavior.?The triad (developer, customer, tester) specifies the external behavior.??The developer implements the internal behavior that creates that external behavior.?This article describes how the external and internal behaviors vary between different domains.?
The external behavior forms the upper left of the testing matrix [i]?and the internal behavior forms the lower left of this matrix:
External Behavior Driven Applications
In many domains such as finance and insurance, an application’s behavior is specified in detail by the Customer.????One way to describe this behavior is through scenarios, using the Gherkin syntax.??The scenario provides a common understanding of what the application should do.???An example of a scenario is:
Scenario: Transfer money to another account
Given customers have accounts
| Customer?| Balance?|
| Sam??????| $100????|
| Bill?????| $50?????|
When customer does a transfer
| Customer?| Recipient?| Amount?|
| Sam??????| Bill??????| $10????|
Then accounts are now
| Customer?| Balance?|
| Sam??????| $90?????|
| Bill?????| $60?????|
These scenarios form the basis for the customer tests (the upper left of the matrix).?One benefit of writing in the Gherkin format, is that they can easily be used as tests.??You need to set up two accounts, make the transfer, and then check that the amounts are correct.?That is, everything is executed according the Given and When in the scenario and the Then is:
Then CHECK accounts are now
| Customer?| Balance?|
| Sam??????| $90?????|
| Bill?????| $60?????|
There can be many alternative scenarios based on the amount of the transfer, the number of transactions, and so forth.??The results are typically defined by the customer perspective.??For example:
Scenario: Attempt to transfer amount over balance generates an error
Given customers have accounts
| Customer?| Balance?|
| Sam??????| $100????|
| Bill?????| $50?????|
When customer requests a transfer
| Customer?| Recipient?| Amount?|
| Sam??????| Bill??????| $120???|
Then transferred is denied and output is
| Message???????????????????????|
| Insufficient funds to transfer |
?Often one creates additional scenarios which represent the business rules or the ubiquitous language.??For example, in the above scenario, there could be a business rule that states that the transfer must be no greater than ? of the balance:
Scenario: Business Rule Amount in a Transfer
* Transfer amount must no greater than 1/2 of the balance
| Amount?| Balance?| Allowed?| Notes???????|
| $50.00?| $100????| yes?????| at limit????|
| $50.01?| $100????| no??????| above limit?|
?In this domain, much of the application’s behavior is from the customer perspective.?
Mostly Internal Behavior Driven Applications
In some domains, the triad only specifies less detailed behavior.??For example, an application that delivers videos might have the scenario:
领英推荐
Scenario: Watch a movie
Given a customer wants to watch a movie
When the movie is playing
Then the movie plays smoothly without any noticeable pauses
There might be a performance requirement (lower right of testing matrix) for a large number of users:
Scenario: Lots of people watching movies
Given a million customers wanting to watch a movie
When the movies are playing
Then each movie plays smoothly without any noticeable pauses
The triad might have more detail such as what “noticeable pauses” means.?They may specify tests for other properties.???Most of the work will be in implementing the internal behavior, such as how to represent the video stream, the caching that is required, and so forth.??
In other domains, the triad could specify scenarios that show the form of the desired output, such as:
Scenario: Determine the fastest route between two points?
Given a set of data on streets
When the user requests the fastest way to go from
| Current location?| Destination????????????|
| 732 Ninth Street?| 1802 West Main Street??|
Then the result is
| Drive???????????????| Distance??|
| South on 9th Street?| .2 miles??|
| Left onto West Main?| .1 miles??|
The triad may create scenarios that show variations of requests and output, such as shortest route, route with the fewest number of left turns, long trips across the country, a trip that cannot be made because there is no street to the destination.??However, most of the effort will be in the internal design of the algorithm that produces the results.
There are other applications where the desired behavior can be specified, but more in terms of statistics.?This often occurs with artificial intelligence systems:
Scenario: Determine the objects in an image
Given input files are:
| Image File????| Object?????????|
| something.jpg?| African Lion???|
| other.jpg?????| Siberian Tiger?|
| someother.jpg?| Black Bear?????|
# … more
When input is processed
Then at least 95% of objects are correct.
Internal Behavior Driven
For some implementations, the internal behavior is split into separate executable components (e.g., services or microservices).???The triad concept can be applied to these components using slightly different terminology:
·????????Consumer – user(s) of a service
·????????Provider – developer of a service
·????????Tester – critically analyzes a service and its implementation
The internal triad specifies the behavior of a component.??They can use scenarios written in the implementation language, in Gherkin, or in another form – whichever is most effective.????
Summary
There is a spectrum of external and internal behavior across application domains.??For some domains, the external behavior is largely specified by the triad.??In this case, having readable scenarios that document that behavior is beneficial.?Behavior Driven Development / Acceptance Test-Driven Development is a process for creating those scenarios.??For other domains, the external behavior can be specified, but most of the detail is in the internal behavior.??Technical practices such as ObjectOriented Design, Interface Oriented Design, Test Driven Development, patterns, and so forth help in creating that internal behavior.??