'. '

Never update tests

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (04:15, 20 October 2021) (edit) (undo)
(Never Update API Tests)
 
Line 3: Line 3:
=== Never Update [[API]] Tests ===
=== 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''.
+
An [[API]] without tests is like cake without a 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]]:
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]]:

Current revision

Keeping BackwardCompatibility helps distributed development. How shall one recognize an incompatible change?

Never Update API Tests

An API without tests is like cake without a 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:

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 configure construction of a newer version of an API object

Summary

If you want your API to be backward compatible, then: Never update tests for your API! Copy them and create new ones!

Personal tools
buy