Never update tests - Revision history

JaroslavTulach: /* Never Update API Tests */

JaroslavTulach — Wed, 20 Oct 2021 04:15:56 GMT

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

JaroslavTulach — Thu, 24 Jan 2019 04:03:17 GMT

←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.

JaroslavTulach — Thu, 24 Jan 2019 03:59:51 GMT

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

JaroslavTulach — Thu, 24 Jan 2019 03:58:50 GMT

←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

JaroslavTulach — Thu, 24 Jan 2019 03:58:05 GMT

←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

JaroslavTulach — Thu, 24 Jan 2019 03:57:34 GMT

←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

JaroslavTulach — Thu, 24 Jan 2019 03:56:29 GMT

←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

JaroslavTulach — Wed, 07 Nov 2012 01:15:41 GMT

Redirecting to BackwardCompatibility

New page

#REDIRECT [[BackwardCompatibility]]