JaroslavTulach: /* Never Update API Tests */ - 2021-10-20 04:15:56

Never Update API Tests

←Older revision Revision as of 04:15, 20 October 2021
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]]:

JaroslavTulach at 04:03, 24 January 2019 - 2019-01-24 04:03:17

←Older revision Revision as of 04:03, 24 January 2019
Line 12: Line 12:
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]]:
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
* 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
+
* Add new constructors, or add a [[builder]] to configure construction of a newer version of an [[API]] object
== Summary ==
== Summary ==

JaroslavTulach: Incompatible moved to Never update tests: Witness incompatible change by the need to update tests. - 2019-01-24 03:59:51

Incompatible moved to Never update tests: Witness incompatible change by the need to update tests.

←Older revision Revision as of 03:59, 24 January 2019

JaroslavTulach at 03:58, 24 January 2019 - 2019-01-24 03:58:50

←Older revision Revision as of 03:58, 24 January 2019
Line 17: Line 17:
If you want your [[API]] to be [[BackwardCompatibility|backward compatible]], then: Never update tests for your [[API]]! Copy them and create new ones!
If you want your [[API]] to be [[BackwardCompatibility|backward compatible]], then: Never update tests for your [[API]]! Copy them and create new ones!
 +
 +
[[Category:APIDesignPatterns:Tests]] [[Category:APIDesignPatterns]]

JaroslavTulach at 03:58, 24 January 2019 - 2019-01-24 03:58:05

←Older revision Revision as of 03:58, 24 January 2019
Line 13: Line 13:
* Don't modify existing behavior, but provide [[AlternativeBehavior]] with compile time alternatives
* 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
* Add new constructors, or add a [[builder]] to construct newer version of an [[API]] object
 +
 +
== Summary ==
If you want your [[API]] to be [[BackwardCompatibility|backward compatible]], then: Never update tests for your [[API]]! Copy them and create new ones!
If you want your [[API]] to be [[BackwardCompatibility|backward compatible]], then: Never update tests for your [[API]]! Copy them and create new ones!

JaroslavTulach at 03:57, 24 January 2019 - 2019-01-24 03:57:34

←Older revision Revision as of 03:57, 24 January 2019
Line 1: Line 1:
-
Keeping [[BackwardCompatibility]] helps [[distributed development]]. However shall one recognize an [[incompatible]] change?
+
Keeping [[BackwardCompatibility]] helps [[distributed development]]. How 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 ===
=== Never Update [[API]] Tests ===
Line 19: Line 15:
If you want your [[API]] to be [[BackwardCompatibility|backward compatible]], then: Never update tests for your [[API]]! Copy them and create new ones!
If you want your [[API]] to be [[BackwardCompatibility|backward compatible]], then: Never update tests for your [[API]]! Copy them and create new ones!
-
 
-
[[TBD]]
 

JaroslavTulach at 03:56, 24 January 2019 - 2019-01-24 03:56:29

←Older revision Revision as of 03:56, 24 January 2019
Line 1: Line 1:
-
#REDIRECT [[BackwardCompatibility]]
+
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]]

JaroslavTulach: Redirecting to BackwardCompatibility - 2012-11-07 01:15:41

Redirecting to BackwardCompatibility

New page

#REDIRECT [[BackwardCompatibility]]