Improved Testability Leads to Better Design - Revision history

Kevlin: Economic Testability moved to Improved Testability Leads to Better Design

2009-08-06T14:40:27Z

Economic Testability moved to Improved Testability Leads to Better Design

←Older revision

Revision as of 14:40, 6 August 2009

Kevlin at 17:13, 4 August 2009

2009-08-04T17:13:06Z

←Older revision		Revision as of 17:13, 4 August 2009
Line 5:		Line 5:
	Progressive testing is often stymied because certain necessary functions have not yet been implemented. For example, a common occurrence involves an object that needs to be tested, but makes use of a yet-to-be-built object. An incompleteness that means the test cannot be run. A way around this is to allow the provision of the yet-to-be-built object via a parametrized constructor: When testing we can provide a test double object without changing the internals at all; in the production code we can provide the real (tested) object to deliver the required functionality. The API of the test double and the production object are identical and the object under test is unaware of whether it is running in a test or a production environment.		Progressive testing is often stymied because certain necessary functions have not yet been implemented. For example, a common occurrence involves an object that needs to be tested, but makes use of a yet-to-be-built object. An incompleteness that means the test cannot be run. A way around this is to allow the provision of the yet-to-be-built object via a parametrized constructor: When testing we can provide a test double object without changing the internals at all; in the production code we can provide the real (tested) object to deliver the required functionality. The API of the test double and the production object are identical and the object under test is unaware of whether it is running in a test or a production environment.

-		+	We can go further of course — a lot further. This very soft style of building systems brings advantages all down the line when compared to the hard-wired logic commonly encountered in code. For example, if we need to introduce some kind of logging trail for complex bug diagnosis during development, we can provide the logging logic via the constructor parameters, using the plug-in technique already outlined. In production, using the ''null object'' pattern (which will provide a "do nothing" object with the same API as the logger), we can replace the logger with a harmless null alternative. This means of course that the code being monitored is unchanged, an important point for some types of bug. Should it be necessary that you dynamically enable logging in production mode, this technique makes it very simple to enable or disable logging dynamically — or indeed anything else that you need. Then we have a production system that gracefully slips into logging mode when needed. It may be unfortunate that you should need to do this, but if you do, then sensible application of these techniques can be seriously reputation enhancing!
-	We can go further of course — a lot further. This very soft style of building systems brings advantages all down the line when compared to the hard-wired logic ~~which is~~ commonly encountered. For example, if we need to introduce some kind of logging trail for complex bug diagnosis during development, we can provide the logging logic via the plug-in technique outlined ~~above, via the constructor parameters~~. In production, using the ''null object'' pattern (which will provide a "do nothing" object with the same API as the logger), we can replace the logger with a harmless null alternative. This ~~meams~~ of course that the code being ~~logged /~~ monitored is unchanged, an important point for some types of bug. Should it be necessary that you dynamically enable logging in production mode, this technique makes it very simple to ~~control the dynamically switch / on off dynamic~~ logging (or indeed anything else that you need). Then we have a production system that gracefully slips into logging mode when needed. It may be unfortunate that you should need to do this, but if you do, then sensible application of these techniques can be seriously reputation-enhancing!!	+

Gbcambridge at 13:58, 4 August 2009

2009-08-04T13:58:32Z

←Older revision		Revision as of 13:58, 4 August 2009
Line 6:		Line 6:


-	We can go further of course — a lot further. If we need to introduce some kind of logging trail for complex bug diagnosis during development, we can provide the logging logic via the plug-in technique outlined above, ~~providing the logging object in~~ the constructor parameters. In production, using the ''null object'' pattern (which will provide a "do nothing" object with the same API as the logger), we can replace the logger with a harmless null alternative. This meams of course that the code being logged / monitored is unchanged, an important point for some types of bug. Should it be necessary that you dynamically enable logging in production mode, this technique makes it very simple to control the dynamically switch / on off dynamic logging (or indeed anything else that you need). Then we have a production system that gracefully slips into logging mode when needed. It may be unfortunate that you should need to do this, but if you do, then sensible application of these techniques can be seriously reputation-enhancing!!	+	We can go further of course — a lot further. This very soft style of building systems brings advantages all down the line when compared to the hard-wired logic which is commonly encountered. For example, if we need to introduce some kind of logging trail for complex bug diagnosis during development, we can provide the logging logic via the plug-in technique outlined above, via the constructor parameters. In production, using the ''null object'' pattern (which will provide a "do nothing" object with the same API as the logger), we can replace the logger with a harmless null alternative. This meams of course that the code being logged / monitored is unchanged, an important point for some types of bug. Should it be necessary that you dynamically enable logging in production mode, this technique makes it very simple to control the dynamically switch / on off dynamic logging (or indeed anything else that you need). Then we have a production system that gracefully slips into logging mode when needed. It may be unfortunate that you should need to do this, but if you do, then sensible application of these techniques can be seriously reputation-enhancing!!

Gbcambridge at 16:02, 2 August 2009

2009-08-02T16:02:42Z

←Older revision		Revision as of 16:02, 2 August 2009
Line 1:		Line 1:
-	''Economic Testability'' is a simple concept yet one seen infrequently in practice. Essentially, it boils down to recognizing that since code-testing should be a requirement and that we have in place some nice, economical, standard tools for testing (such as xUnit, Fit, etc.), then the products that we build should always satisfy the requirement of ease-of-test in addition to any other requirements. Happily the ease-of-test requirement reinforces rather than contradicts best practice.	+	''Economic Testability'' is a simple concept yet one seen infrequently in practice. Essentially, it boils down to recognizing that since code-testing should be a requirement and that we have in place some nice, economical, standard tools for testing (such as xUnit, Fit, etc.), then the products that we build should always satisfy the new requirement of ease-of-test, in addition to any other requirements. Happily the ease-of-test requirement reinforces rather than contradicts best practice.
		+
		+	If you build your systems so that testing is made economic — while simultaneously of course preserving simplicity in the production model — the interfaces that you finally end up with are likely to be greatly improved over the one-environment system. Code which has to operate successfully and unchanged in two or more environments (the test and production environments) must pay more than lip service to clean interfaces and maximum encapsulation if the task of embedding within the multiple environments is not to become overwhelming. The discipline needed leads to better design and more modular construction. It really is a win–win situation.

	Progressive testing is often stymied because certain necessary functions have not yet been implemented. For example, a common occurrence involves an object that needs to be tested, but makes use of a yet-to-be-built object. An incompleteness that means the test cannot be run. A way around this is to allow the provision of the yet-to-be-built object via a parametrized constructor: When testing we can provide a test double object without changing the internals at all; in the production code we can provide the real (tested) object to deliver the required functionality. The API of the test double and the production object are identical and the object under test is unaware of whether it is running in a test or a production environment.		Progressive testing is often stymied because certain necessary functions have not yet been implemented. For example, a common occurrence involves an object that needs to be tested, but makes use of a yet-to-be-built object. An incompleteness that means the test cannot be run. A way around this is to allow the provision of the yet-to-be-built object via a parametrized constructor: When testing we can provide a test double object without changing the internals at all; in the production code we can provide the real (tested) object to deliver the required functionality. The API of the test double and the production object are identical and the object under test is unaware of whether it is running in a test or a production environment.

-	We can go further of course — a lot further. If we need to introduce some kind of logging trail for complex bug diagnosis, we can provide the logging logic via the plug-in technique outlined above, providing the logging object in the constructor parameters. In production, using the ''null object'' pattern (which will provide a "do nothing" object with the same API as the logger), we can replace the logger with a harmless null alternative. If it is possible that you need to dynamically enable logging in production mode, this technique makes it very simple. Then we have a production system that gracefully slips into logging mode when needed. It may be unfortunate that you should need to do this, but if you do, then you can look like a hero, i.e., a professional!

-	~~If you build your systems so that testing is made economic — while simultaneously~~ of course ~~preserving simplicity in the production model~~ — ~~the interfaces that you finally end up with are likely~~ to ~~be greatly improved over~~ the ~~one~~-~~environment system. Code which has to operate successfully and unchanged~~ in ~~two or more environments (~~the ~~test and~~ production ~~environments~~) ~~must pay more than lip service to clean interfaces and maximum encapsulation if~~ the ~~task~~ of ~~embedding within~~ the ~~multiple environments~~ is ~~not to become overwhelming~~. ~~The discipline needed leads~~ to ~~better design and more modular construction~~. ~~It really is~~ a ~~win–win situation~~.	+	We can go further of course — a lot further. If we need to introduce some kind of logging trail for complex bug diagnosis during development, we can provide the logging logic via the plug-in technique outlined above, providing the logging object in the constructor parameters. In production, using the ''null object'' pattern (which will provide a "do nothing" object with the same API as the logger), we can replace the logger with a harmless null alternative. This meams of course that the code being logged / monitored is unchanged, an important point for some types of bug. Should it be necessary that you dynamically enable logging in production mode, this technique makes it very simple to control the dynamically switch / on off dynamic logging (or indeed anything else that you need). Then we have a production system that gracefully slips into logging mode when needed. It may be unfortunate that you should need to do this, but if you do, then sensible application of these techniques can be seriously reputation-enhancing!!
		+
		+

	By [[George Brooke]]		By [[George Brooke]]

Kevlin at 13:46, 1 August 2009

2009-08-01T13:46:32Z

←Older revision		Revision as of 13:46, 1 August 2009
Line 1:		Line 1:
-	''Economic Testability'' is a simple concept ~~but infrequently~~ seen in practice. Essentially it boils down to recognizing that since code-testing should be a requirement and that we have in place some nice, economical, standard tools for testing (such as xUnit, Fit, etc.), then the products that we build should always satisfy the requirement of ease-of-test in addition to any other requirements. Happily the ease-of-test requirement reinforces rather than contradicts best practice.	+	''Economic Testability'' is a simple concept yet one seen infrequently in practice. Essentially, it boils down to recognizing that since code-testing should be a requirement and that we have in place some nice, economical, standard tools for testing (such as xUnit, Fit, etc.), then the products that we build should always satisfy the requirement of ease-of-test in addition to any other requirements. Happily the ease-of-test requirement reinforces rather than contradicts best practice.

-	Progressive testing is often stymied because certain necessary functions have not yet been implemented. For example, an object needs to be tested but it makes use of a yet-to-be-built object ~~is a pretty common occurrence~~. A way around this is to allow the provision of the yet-to-be-built object via a parametrized constructor: When testing we can provide a test double object without changing the internals at all; in the production code we can provide the real (tested) object to deliver the required functionality. The API of the test double and the production object are identical and the object under test is unaware of whether it is running in a test or a production environment.	+	Progressive testing is often stymied because certain necessary functions have not yet been implemented. For example, a common occurrence involves an object that needs to be tested, but makes use of a yet-to-be-built object. An incompleteness that means the test cannot be run. A way around this is to allow the provision of the yet-to-be-built object via a parametrized constructor: When testing we can provide a test double object without changing the internals at all; in the production code we can provide the real (tested) object to deliver the required functionality. The API of the test double and the production object are identical and the object under test is unaware of whether it is running in a test or a production environment.

-	We can go further of course — a lot further. If we need to introduce some kind of logging trail for complex bug diagnosis, we can provide the logging logic via the plug-in technique outlined above, providing the logging object in the constructor parameters. In production, using the ''null object'' pattern (which will provide a "do-nothing" object with the same API as the logger), we can replace the logger with a harmless null-alternative. If it is possible that you need to dynamically enable logging in production mode, this technique makes it very simple. Then we have a production system that gracefully slips into logging mode when needed. It may be unfortunate that you should need to do this, but if you do, then you can look like a hero, i.e., a professional!	+	We can go further of course — a lot further. If we need to introduce some kind of logging trail for complex bug diagnosis, we can provide the logging logic via the plug-in technique outlined above, providing the logging object in the constructor parameters. In production, using the ''null object'' pattern (which will provide a "do nothing" object with the same API as the logger), we can replace the logger with a harmless null alternative. If it is possible that you need to dynamically enable logging in production mode, this technique makes it very simple. Then we have a production system that gracefully slips into logging mode when needed. It may be unfortunate that you should need to do this, but if you do, then you can look like a hero, i.e., a professional!

-	If you build your systems so that testing is made economic — while simultaneously of course preserving simplicity in the production model — the interfaces that you finally end up with are likely to be greatly improved over the one-environment system. Code which has to operate successfully and unchanged in two or more environments (the test and production environments) must pay more than lip-service to clean interfaces and maximum encapsulation if the task of embedding within the multiple environments is not to become overwhelming. The discipline needed leads to better design and more modular construction. It really is a win–win situation.	+	If you build your systems so that testing is made economic — while simultaneously of course preserving simplicity in the production model — the interfaces that you finally end up with are likely to be greatly improved over the one-environment system. Code which has to operate successfully and unchanged in two or more environments (the test and production environments) must pay more than lip service to clean interfaces and maximum encapsulation if the task of embedding within the multiple environments is not to become overwhelming. The discipline needed leads to better design and more modular construction. It really is a win–win situation.

	By [[George Brooke]]		By [[George Brooke]]

Gbcambridge at 15:54, 31 July 2009

2009-07-31T15:54:48Z

←Older revision		Revision as of 15:54, 31 July 2009
Line 1:		Line 1:
-	''Economic Testability'' is a simple concept but ~~not one often~~ seen in practice. Essentially it boils down to recognizing that since ~~tested~~ code should be a requirement, and that we have in place some nice, economical, standard tools for testing (such as xUnit, Fit, etc.), then the products that we build should always satisfy the requirement of ease-of-test in addition to other requirements. Happily ~~this~~ requirement reinforces rather than contradicts best practice.	+	''Economic Testability'' is a simple concept but infrequently seen in practice. Essentially it boils down to recognizing that since code-testing should be a requirement and that we have in place some nice, economical, standard tools for testing (such as xUnit, Fit, etc.), then the products that we build should always satisfy the requirement of ease-of-test in addition to any other requirements. Happily the ease-of-test requirement reinforces rather than contradicts best practice.

-	Progressive testing is often stymied because certain ~~major~~ functions have not yet been implemented. For example, an object needs to be tested but it makes use of a yet-to-be-built object is a pretty common occurrence. A way around this is to allow the provision of the yet-to-be-built object via a ~~parameterized~~ constructor: When testing we can provide a ~~dummy~~ object without changing the internals at all; in the production code we can provide the real (tested) object to deliver the required functionality. The ~~actual method signatures~~ are ~~unchanged~~ and the object under test is unaware of whether it is running in a test or a production environment.	+	Progressive testing is often stymied because certain necessary functions have not yet been implemented. For example, an object needs to be tested but it makes use of a yet-to-be-built object is a pretty common occurrence. A way around this is to allow the provision of the yet-to-be-built object via a parametrized constructor: When testing we can provide a test double object without changing the internals at all; in the production code we can provide the real (tested) object to deliver the required functionality. The API of the test double and the production object are identical and the object under test is unaware of whether it is running in a test or a production environment.

-	We can go further of course — a lot further. If we ~~wanted~~ to introduce some kind of logging trail for complex bug diagnosis, we can provide the logging logic via the plug-in technique outlined above, providing the logging object in the constructor parameters. In production, using the ''null object'' pattern, we can replace the logger with a harmless alternative. ~~On the other hand~~, ~~why not make~~ this ~~dynamically selectable?~~ Then we ~~would~~ have a production system that ~~could~~ gracefully ~~slip~~ into logging mode. It may be unfortunate that you should need to do this, but if you do, then you can look like a hero, i.e., a professional!	+	We can go further of course — a lot further. If we need to introduce some kind of logging trail for complex bug diagnosis, we can provide the logging logic via the plug-in technique outlined above, providing the logging object in the constructor parameters. In production, using the ''null object'' pattern (which will provide a "do-nothing" object with the same API as the logger), we can replace the logger with a harmless null-alternative. If it is possible that you need to dynamically enable logging in production mode, this technique makes it very simple. Then we have a production system that gracefully slips into logging mode when needed. It may be unfortunate that you should need to do this, but if you do, then you can look like a hero, i.e., a professional!

-	If you build your systems so that testing is made ~~simple~~ — while simultaneously of course preserving simplicity in the production model — the interfaces that you finally end up with is likely to be greatly improved. ~~It is superior~~ in ~~terms of encapsulation~~ and ~~portability~~ than if ~~you had built you system with just one target environment in mind~~. The discipline ~~involved in creating an interface that is equally at home in two environments causes you~~ to ~~do a~~ better ~~job in the~~ design ~~essentials than otherwise~~. It really is a win–win situation.	+	If you build your systems so that testing is made economic — while simultaneously of course preserving simplicity in the production model — the interfaces that you finally end up with are likely to be greatly improved over the one-environment system. Code which has to operate successfully and unchanged in two or more environments (the test and production environments) must pay more than lip-service to clean interfaces and maximum encapsulation if the task of embedding within the multiple environments is not to become overwhelming. The discipline needed leads to better design and more modular construction. It really is a win–win situation.

	By [[George Brooke]]		By [[George Brooke]]

Kevlin at 13:59, 30 July 2009

2009-07-30T13:59:22Z

←Older revision		Revision as of 13:59, 30 July 2009
Line 1:		Line 1:
-	''Economic Testability'' is a simple concept but not one often seen in practice. Essentially it boils down to recognizing that since tested code should be a requirement, and that we have in place some nice, economical, standard tools for testing (such as xUnit, Fit, etc.), then the products that we build should always satisfy the requirement of ease-of-test in addition to ~~any~~ other requirements. Happily this requirement reinforces rather than contradicts best practice. ~~Perhaps a few examples will help?~~	+	''Economic Testability'' is a simple concept but not one often seen in practice. Essentially it boils down to recognizing that since tested code should be a requirement, and that we have in place some nice, economical, standard tools for testing (such as xUnit, Fit, etc.), then the products that we build should always satisfy the requirement of ease-of-test in addition to other requirements. Happily this requirement reinforces rather than contradicts best practice.

-	It is often ~~the case that tests are impeded~~ because certain major functions ~~are~~ not yet implemented. For example,an object needs to be tested but it makes use of a yet-to-be-built object is a pretty common occurrence. A way around this is to allow the provision of the yet-to-be-built object via a parameterized constructor~~. Then, in the test-case situation~~ we can provide a dummy object without changing the internals at all; in the production ~~model~~ we can provide the real (tested) object to deliver the required functionality. ~~When implemented via the constructor, as recommended, in the set-up region of the tests, the~~ actual method signatures are ~~not changed at all~~.	+	Progressive testing is often stymied because certain major functions have not yet been implemented. For example, an object needs to be tested but it makes use of a yet-to-be-built object is a pretty common occurrence. A way around this is to allow the provision of the yet-to-be-built object via a parameterized constructor: When testing we can provide a dummy object without changing the internals at all; in the production code we can provide the real (tested) object to deliver the required functionality. The actual method signatures are unchanged and the object under test is unaware of whether it is running in a test or a production environment.

-	We can go further of course .. a lot further. If we wanted to introduce some kind of logging-trail for complex bug diagnosis, ~~then~~ we can provide the logging logic via the technique outlined above, by providing the logging object in the constructor parameters. At production ~~time~~, using the null-object pattern, we can replace the logger with a harmless alternative. On the other hand, why not make this dynamically selectable? Then we ~~could~~ have a production system ~~which can~~ gracefully slip into logging mode. It may be unfortunate that you should need to do this, but if you do, then you can look like a hero, i.e., a professional!	+	We can go further of course — a lot further. If we wanted to introduce some kind of logging trail for complex bug diagnosis, we can provide the logging logic via the plug-in technique outlined above, providing the logging object in the constructor parameters. In production, using the ''null object'' pattern, we can replace the logger with a harmless alternative. On the other hand, why not make this dynamically selectable? Then we would have a production system that could gracefully slip into logging mode. It may be unfortunate that you should need to do this, but if you do, then you can look like a hero, i.e., a professional!

-	~~Finally, if~~ you build your systems so that testing is made simple~~, either by following the suggestion here, or by just making the interfaces very simple to use in the xUnit world, and~~ simultaneously of course preserving simplicity in the production model~~, then our experience has been that~~ the interfaces that you finally end up with ~~are~~ superior in terms of encapsulation and portability than if you had built you system with just one target environment in mind. ~~In other words, the~~ discipline in ~~building~~ an interface ~~which~~ is equally at home in two environments causes you to do a better job in the design-essentials than otherwise. It really is a win-win situation.	+	If you build your systems so that testing is made simple — while simultaneously of course preserving simplicity in the production model — the interfaces that you finally end up with is likely to be greatly improved. It is superior in terms of encapsulation and portability than if you had built you system with just one target environment in mind. The discipline involved in creating an interface that is equally at home in two environments causes you to do a better job in the design essentials than otherwise. It really is a win–win situation.

	By [[George Brooke]]		By [[George Brooke]]

Kevlin at 11:59, 30 July 2009

2009-07-30T11:59:56Z

←Older revision		Revision as of 11:59, 30 July 2009
Line 1:		Line 1:
-	"Economic Testability" is a simple concept but not often seen in practice. Essentially it boils down to ~~recognising~~ that since tested code is a requirement and that we have some nice, economical, ~~standards~~ for testing ~~in place~~ (such as xUnit, Fit, etc), then the products that we build should always satisfy the requirement of ease-of-test in addition to any other requirements. Happily this requirement ~~does not contradict, but~~ reinforces best practice. Perhaps a few examples will help?	+	''Economic Testability'' is a simple concept but not one often seen in practice. Essentially it boils down to recognizing that since tested code should be a requirement, and that we have in place some nice, economical, standard tools for testing (such as xUnit, Fit, etc.), then the products that we build should always satisfy the requirement of ease-of-test in addition to any other requirements. Happily this requirement reinforces rather than contradicts best practice. Perhaps a few examples will help?

	It is often the case that tests are impeded because certain major functions are not yet implemented. For example,an object needs to be tested but it makes use of a yet-to-be-built object is a pretty common occurrence. A way around this is to allow the provision of the yet-to-be-built object via a parameterized constructor. Then, in the test-case situation we can provide a dummy object without changing the internals at all; in the production model we can provide the real (tested) object to deliver the required functionality. When implemented via the constructor, as recommended, in the set-up region of the tests, the actual method signatures are not changed at all.		It is often the case that tests are impeded because certain major functions are not yet implemented. For example,an object needs to be tested but it makes use of a yet-to-be-built object is a pretty common occurrence. A way around this is to allow the provision of the yet-to-be-built object via a parameterized constructor. Then, in the test-case situation we can provide a dummy object without changing the internals at all; in the production model we can provide the real (tested) object to deliver the required functionality. When implemented via the constructor, as recommended, in the set-up region of the tests, the actual method signatures are not changed at all.
Line 6:		Line 6:

	Finally, if you build your systems so that testing is made simple, either by following the suggestion here, or by just making the interfaces very simple to use in the xUnit world, and simultaneously of course preserving simplicity in the production model, then our experience has been that the interfaces that you finally end up with are superior in terms of encapsulation and portability than if you had built you system with just one target environment in mind. In other words, the discipline in building an interface which is equally at home in two environments causes you to do a better job in the design-essentials than otherwise. It really is a win-win situation.		Finally, if you build your systems so that testing is made simple, either by following the suggestion here, or by just making the interfaces very simple to use in the xUnit world, and simultaneously of course preserving simplicity in the production model, then our experience has been that the interfaces that you finally end up with are superior in terms of encapsulation and portability than if you had built you system with just one target environment in mind. In other words, the discipline in building an interface which is equally at home in two environments causes you to do a better job in the design-essentials than otherwise. It really is a win-win situation.
		+
		+	By [[George Brooke]]
		+
		+	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Gbcambridge: Planning for testing will improve your overall design

2009-03-04T13:30:01Z

Planning for testing will improve your overall design

New page

"Economic Testability" is a simple concept but not often seen in practice. Essentially it boils down to recognising that since tested code is a requirement and that we have some nice, economical, standards for testing in place (such as xUnit, Fit, etc), then the products that we build should always satisfy the requirement of ease-of-test in addition to any other requirements. Happily this requirement does not contradict, but reinforces best practice. Perhaps a few examples will help?

It is often the case that tests are impeded because certain major functions are not yet implemented. For example,an object needs to be tested but it makes use of a yet-to-be-built object is a pretty common occurrence. A way around this is to allow the provision of the yet-to-be-built object via a parameterized constructor. Then, in the test-case situation we can provide a dummy object without changing the internals at all; in the production model we can provide the real (tested) object to deliver the required functionality. When implemented via the constructor, as recommended, in the set-up region of the tests, the actual method signatures are not changed at all.

We can go further of course .. a lot further. If we wanted to introduce some kind of logging-trail for complex bug diagnosis, then we can provide the logging logic via the technique outlined above, by providing the logging object in the constructor parameters. At production time, using the null-object pattern, we can replace the logger with a harmless alternative. On the other hand, why not make this dynamically selectable? Then we could have a production system which can gracefully slip into logging mode. It may be unfortunate that you should need to do this, but if you do, then you can look like a hero, i.e., a professional!

Finally, if you build your systems so that testing is made simple, either by following the suggestion here, or by just making the interfaces very simple to use in the xUnit world, and simultaneously of course preserving simplicity in the production model, then our experience has been that the interfaces that you finally end up with are superior in terms of encapsulation and portability than if you had built you system with just one target environment in mind. In other words, the discipline in building an interface which is equally at home in two environments causes you to do a better job in the design-essentials than otherwise. It really is a win-win situation.