Never update tests
From APIDesign
(Redirecting to BackwardCompatibility) |
|||
| Line 1: | Line 1: | ||
| - | + | Keeping [[BackwardCompatibility]] helps [[distributed development]]. However shall one recognize an [[incompatible]] change? | |
| + | |||
| + | == [[Incompatible]] Change == | ||
| + | |||
| + | There are three basic ways to break [[BackwardCompatibility]]: either break source, binary or functional aspects of a code that is using your [[API]]. | ||
| + | |||
| + | === Never Update [[API]] Tests === | ||
| + | |||
| + | An [[API]] without tests is like cake without ketchup. Thus let's assume there are some tests checking behavior of the [[API]]. The first sign of an [[incompatible]] change is the ''need to update tests''. | ||
| + | |||
| + | If you are changing an [[API]] and you have to update tests because they no longer compile, then you have broken [[Source_Compatibility]]. Common mistakes include adding new methods into interfaces or '''abstract''' methods into subclassable classes. Consider following [[API Design Patterns]]: | ||
| + | * Follow [[ExtendingInterfaces]] advice to extend interfaces in the classical way | ||
| + | * You may be tempted to use [[DefaultMethods]] - but use with care, they increase [[fuzziness]] | ||
| + | * [[Abstract class]] in an [[API]] is suspicious, but they can also accept methods with default implementations | ||
| + | |||
| + | When you have to update your [[API]] tests, because they are failing, you have probably broken [[functional compatibility]] of your [[API]]. Don't do that, rather try following [[API Design Patterns]]: | ||
| + | * Don't modify existing behavior, but provide [[AlternativeBehavior]] with compile time alternatives | ||
| + | * Add new constructors, or add a [[builder]] to construct newer version of an [[API]] object | ||
| + | |||
| + | If you want your [[API]] to be [[BackwardCompatibility|backward compatible]], then: Never update tests for your [[API]]! Copy them and create new ones! | ||
| + | |||
| + | [[TBD]] | ||
Revision as of 03:56, 24 January 2019
Keeping BackwardCompatibility helps distributed development. However shall one recognize an incompatible change?
Incompatible Change
There are three basic ways to break BackwardCompatibility: either break source, binary or functional aspects of a code that is using your API.
Never Update API Tests
An API without tests is like cake without ketchup. Thus let's assume there are some tests checking behavior of the API. The first sign of an incompatible change is the need to update tests.
If you are changing an API and you have to update tests because they no longer compile, then you have broken Source_Compatibility. Common mistakes include adding new methods into interfaces or abstract methods into subclassable classes. Consider following API Design Patterns:
- Follow ExtendingInterfaces advice to extend interfaces in the classical way
- You may be tempted to use DefaultMethods - but use with care, they increase fuzziness
- Abstract class in an API is suspicious, but they can also accept methods with default implementations
When you have to update your API tests, because they are failing, you have probably broken functional compatibility of your API. Don't do that, rather try following API Design Patterns:
- Don't modify existing behavior, but provide AlternativeBehavior with compile time alternatives
- Add new constructors, or add a builder to construct newer version of an API object
If you want your API to be backward compatible, then: Never update tests for your API! Copy them and create new ones!
Follow
