Programmers Who Write Tests Get More Time to Program - Revision history

Kevlin: Programmers who write tests get more time to program moved to Programmers Who Write Tests Get More Time to Program

2009-07-09T06:07:30Z

Programmers who write tests get more time to program moved to Programmers Who Write Tests Get More Time to Program

←Older revision

Revision as of 06:07, 9 July 2009

Kevlin at 06:06, 9 July 2009

2009-07-09T06:06:20Z

←Older revision		Revision as of 06:06, 9 July 2009
Line 1:		Line 1:
	I became a programmer so that I could spend time creating software by programming. I don't want to waste my time managing low-quality code.		I became a programmer so that I could spend time creating software by programming. I don't want to waste my time managing low-quality code.

-	Does your code work the first time ~~your~~ test it out? Mine certainly never does. So if I hand ~~over~~ the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.	+	Does your code work the first time you test it out? Mine certainly never does. So if I hand the code over to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.

	The first thing I do when I'm starting on a programming task is ask myself: "How am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.		The first thing I do when I'm starting on a programming task is ask myself: "How am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.

-	A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?" ~~The~~ chances are that not only will your tests will be better for it, your design will also have improved.	+	A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question "How will I know when my task is complete?" the chances are that not only will your tests will be better for it, your design will also have improved.

	I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use.		I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use.
Line 12:		Line 12:

	# Allow the code to be run synchronously and in-process by a configuration change. The messaging infrastructure is no longer coupled to the business logic. The resulting design is both easier to follow and more flexible, in addition to being easier to test. However, testing still requires setting up a long chain of services.		# Allow the code to be run synchronously and in-process by a configuration change. The messaging infrastructure is no longer coupled to the business logic. The resulting design is both easier to follow and more flexible, in addition to being easier to test. However, testing still requires setting up a long chain of services.
-	# Refactoring my services to calculate the result they send to the next service by using a transformation function ~~made~~ the responsibilities of different parts of the code clearer. And I ~~could~~ test almost all the logic by just calling this transformation function and checking the return value.	+	# Refactoring my services to calculate the result they send to the next service by using a transformation function makes the responsibilities of different parts of the code clearer. And I can test almost all the logic by just calling this transformation function and checking the return value.

	When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very easily" try to write a test anyway. The test will probably require a lot of setup and it may be hard to verify the results. These are design problems, not test problems. Use the information from the testing process to refactor your system to a better design.		When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very easily" try to write a test anyway. The test will probably require a lot of setup and it may be hard to verify the results. These are design problems, not test problems. Use the information from the testing process to refactor your system to a better design.

Jhannes at 12:21, 25 November 2008

2008-11-25T12:21:13Z

←Older revision		Revision as of 12:21, 25 November 2008
Line 12:		Line 12:

	# Allow the code to be run synchronously and in-process by a configuration change. The messaging infrastructure is no longer coupled to the business logic. The resulting design is both easier to follow and more flexible, in addition to being easier to test. However, testing still requires setting up a long chain of services.		# Allow the code to be run synchronously and in-process by a configuration change. The messaging infrastructure is no longer coupled to the business logic. The resulting design is both easier to follow and more flexible, in addition to being easier to test. However, testing still requires setting up a long chain of services.
-
	# Refactoring my services to calculate the result they send to the next service by using a transformation function made the responsibilities of different parts of the code clearer. And I could test almost all the logic by just calling this transformation function and checking the return value.		# Refactoring my services to calculate the result they send to the next service by using a transformation function made the responsibilities of different parts of the code clearer. And I could test almost all the logic by just calling this transformation function and checking the return value.

Kevlin at 11:59, 25 November 2008

2008-11-25T11:59:43Z

←Older revision		Revision as of 11:59, 25 November 2008
Line 3:		Line 3:
	Does your code work the first time your test it out? Mine certainly never does. So if I hand over the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.		Does your code work the first time your test it out? Mine certainly never does. So if I hand over the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.

-	The first thing I do when I'm starting on a programming task ~~it to~~ ask myself "How am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.	+	The first thing I do when I'm starting on a programming task is ask myself: "How am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.

-	A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?", chances are that not only will your tests will be better for it, your design will also have improved.	+	A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?" The chances are that not only will your tests will be better for it, your design will also have improved.

	I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use.		I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use.
Line 11:		Line 11:
	For example, a system that is built with an asynchronous chain of services connected via a message bus might require you to deploy your code before you can test it. I've redesigned such code in a couple of steps that progressively reduced the coupling, improved the cohesion, and simplified the testing of the code:		For example, a system that is built with an asynchronous chain of services connected via a message bus might require you to deploy your code before you can test it. I've redesigned such code in a couple of steps that progressively reduced the coupling, improved the cohesion, and simplified the testing of the code:

-	1. Allow the code to be run synchronously and in-process by a configuration change. The messaging infrastructure is no longer coupled to the business logic. The resulting design is both easier to follow and more flexible, in addition to being easier to test. However, testing still requires setting up a long chain of services.	+	# Allow the code to be run synchronously and in-process by a configuration change. The messaging infrastructure is no longer coupled to the business logic. The resulting design is both easier to follow and more flexible, in addition to being easier to test. However, testing still requires setting up a long chain of services.

-	2. Refactoring my services to calculate the result they send to the next service by using a transformation function made the responsibilities of different parts of the code clearer. And I could test almost all the logic by just calling this transformation function and checking the return value.	+	# Refactoring my services to calculate the result they send to the next service by using a transformation function made the responsibilities of different parts of the code clearer. And I could test almost all the logic by just calling this transformation function and checking the return value.

-	When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very easily," try to write a test anyway. The test will probably require a lot of setup and it may be hard to verify the results. These are design problems, not test problems. Use the information from the testing process to refactor your system to a better design.	+	When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very easily" try to write a test anyway. The test will probably require a lot of setup and it may be hard to verify the results. These are design problems, not test problems. Use the information from the testing process to refactor your system to a better design.

	May you achieve fewer bugs and spend all your days programming happily in a well-designed system!		May you achieve fewer bugs and spend all your days programming happily in a well-designed system!

Jhannes: Trying a new phrasing of the example

2008-11-25T09:24:44Z

Trying a new phrasing of the example

←Older revision		Revision as of 09:24, 25 November 2008
Line 7:		Line 7:
	A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?", chances are that not only will your tests will be better for it, your design will also have improved.		A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?", chances are that not only will your tests will be better for it, your design will also have improved.

-	I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use. For example, a system that is built with an asynchronous chain of services connected via a message bus might require you to deploy your code before you can test it. I've redesigned such code to be able to run synchronously and in-process by a configuration change. The design got better in the bargain as my system is now more flexible and the messaging infrastructure is no longer coupled to the business logic.	+	I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use.

-	~~But I would still have to set up~~ a ~~long~~ chain of services. ~~Reducing the number~~ of ~~asynchronous~~ steps ~~made my tests easier. And~~ the ~~design got even better as~~ the ~~system became simpler to understand~~ and ~~follow.~~	+	For example, a system that is built with an asynchronous chain of services connected via a message bus might require you to deploy your code before you can test it. I've redesigned such code in a couple of steps that progressively reduced the coupling, improved the cohesion, and simplified the testing of the code:

-	~~I still would have~~ to ~~register~~ a ~~callback~~ to ~~get~~ the ~~result~~ of ~~the~~ services ~~chain~~. Refactoring my services to calculate the result they send to the next service by using a transformation function made the responsibilities of different parts of the code clearer. And I could test almost all the logic by just calling this transformation function and checking the return value.	+	1. Allow the code to be run synchronously and in-process by a configuration change. The messaging infrastructure is no longer coupled to the business logic. The resulting design is both easier to follow and more flexible, in addition to being easier to test. However, testing still requires setting up a long chain of services.
		+
		+	2. Refactoring my services to calculate the result they send to the next service by using a transformation function made the responsibilities of different parts of the code clearer. And I could test almost all the logic by just calling this transformation function and checking the return value.

	When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very easily," try to write a test anyway. The test will probably require a lot of setup and it may be hard to verify the results. These are design problems, not test problems. Use the information from the testing process to refactor your system to a better design.		When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very easily," try to write a test anyway. The test will probably require a lot of setup and it may be hard to verify the results. These are design problems, not test problems. Use the information from the testing process to refactor your system to a better design.

Jhannes: An attempt to make the example clearer

2008-11-24T01:08:45Z

An attempt to make the example clearer

←Older revision		Revision as of 01:08, 24 November 2008
Line 1:		Line 1:
-	I became a programmer so that I could spend time creating software by programming. I don't want to ~~spend~~ my time managing low-quality code.	+	I became a programmer so that I could spend time creating software by programming. I don't want to waste my time managing low-quality code.

-	Does your code work the first time your test it out? Mine certainly never does. ~~This means that~~ if I hand over the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.	+	Does your code work the first time your test it out? Mine certainly never does. So if I hand over the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.

-	~~So the~~ first thing I do when I'm starting on a programming task it to ask myself "How am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.	+	The first thing I do when I'm starting on a programming task it to ask myself "How am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.

	A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?", chances are that not only will your tests will be better for it, your design will also have improved.		A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?", chances are that not only will your tests will be better for it, your design will also have improved.

-	I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use. For example, a system that is built with an asynchronous chain of services connected via a message bus might require you to deploy your code before you can test it. I've redesigned such code to be able to run synchronously and in-process by a configuration change. The design got better in the bargain~~. But I would still have to set up a long chain of services. Reducing the number of asynchronous steps made~~ my ~~tests easier. And~~ the ~~design got better. I still would have~~ to ~~register a callback to get the result of the services chain. Refactoring my services to calculate the result they forward using a function call made my design better. And I could test almost all~~ the logic ~~by writing simpler tests~~.	+	I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use. For example, a system that is built with an asynchronous chain of services connected via a message bus might require you to deploy your code before you can test it. I've redesigned such code to be able to run synchronously and in-process by a configuration change. The design got better in the bargain as my system is now more flexible and the messaging infrastructure is no longer coupled to the business logic.

-	When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very ~~well~~," write ~~the~~ test anyway. ~~And use~~ the information to refactor your system to ~~have~~ a better design.	+	But I would still have to set up a long chain of services. Reducing the number of asynchronous steps made my tests easier. And the design got even better as the system became simpler to understand and follow.
		+
		+	I still would have to register a callback to get the result of the services chain. Refactoring my services to calculate the result they send to the next service by using a transformation function made the responsibilities of different parts of the code clearer. And I could test almost all the logic by just calling this transformation function and checking the return value.
		+
		+	When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very easily," try to write a test anyway. The test will probably require a lot of setup and it may be hard to verify the results. These are design problems, not test problems. Use the information from the testing process to refactor your system to a better design.

	May you achieve fewer bugs and spend all your days programming happily in a well-designed system!		May you achieve fewer bugs and spend all your days programming happily in a well-designed system!

Kevlin at 15:30, 22 November 2008

2008-11-22T15:30:16Z

←Older revision		Revision as of 15:30, 22 November 2008
Line 3:		Line 3:
	Does your code work the first time your test it out? Mine certainly never does. This means that if I hand over the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.		Does your code work the first time your test it out? Mine certainly never does. This means that if I hand over the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.

-	So the first thing I do when I'm starting on a programming task it to ask myself "~~how~~ am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.	+	So the first thing I do when I'm starting on a programming task it to ask myself "How am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.

	A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?", chances are that not only will your tests will be better for it, your design will also have improved.		A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?", chances are that not only will your tests will be better for it, your design will also have improved.

Kevlin at 15:22, 22 November 2008

2008-11-22T15:22:51Z

←Older revision		Revision as of 15:22, 22 November 2008
Line 1:		Line 1:
-	I became a programmer so that I could spend time creating software by programming. I don't want to spend my time managing low quality code.	+	I became a programmer so that I could spend time creating software by programming. I don't want to spend my time managing low-quality code.

	Does your code work the first time your test it out? Mine certainly never does. This means that if I hand over the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.		Does your code work the first time your test it out? Mine certainly never does. This means that if I hand over the code to someone else, I'm sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don't want to have to go thought a long manual test myself to verify my code.
Line 5:		Line 5:
	So the first thing I do when I'm starting on a programming task it to ask myself "how am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.		So the first thing I do when I'm starting on a programming task it to ask myself "how am I going to test that this actually works?" I know it has to be done, I know it will take up a lot of my time if I do a poor job of it, so I want to get it right.

-	A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete", chances are your tests will be better for it.	+	A good way to start is by writing tests before you write the code. The tests will specify the required behavior of the code. If you write the tests with the question: "How will I know when my task is complete?", chances are that not only will your tests will be better for it, your design will also have improved.
-		+
-	~~Chances are also that~~ your design will ~~be better for it~~.	+

	I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use. For example, a system that is built with an asynchronous chain of services connected via a message bus might require you to deploy your code before you can test it. I've redesigned such code to be able to run synchronously and in-process by a configuration change. The design got better in the bargain. But I would still have to set up a long chain of services. Reducing the number of asynchronous steps made my tests easier. And the design got better. I still would have to register a callback to get the result of the services chain. Refactoring my services to calculate the result they forward using a function call made my design better. And I could test almost all the logic by writing simpler tests.		I've come to code bases that were otherwise good, but that required me to write a lot of code to support my tests. In other words: The code was overly complex to use. For example, a system that is built with an asynchronous chain of services connected via a message bus might require you to deploy your code before you can test it. I've redesigned such code to be able to run synchronously and in-process by a configuration change. The design got better in the bargain. But I would still have to set up a long chain of services. Reducing the number of asynchronous steps made my tests easier. And the design got better. I still would have to register a callback to get the result of the services chain. Refactoring my services to calculate the result they forward using a function call made my design better. And I could test almost all the logic by writing simpler tests.

-	When encountering a programming task, ask yourself: "How can I test this". If the answer is "Not very well", write the test anyway. And use the information to refactor your system to have a better design.	+	When encountering a programming task, ask yourself: "How can I test this?" If the answer is "Not very well," write the test anyway. And use the information to refactor your system to have a better design.

	May you achieve fewer bugs and spend all your days programming happily in a well-designed system!		May you achieve fewer bugs and spend all your days programming happily in a well-designed system!

Jhannes: Programmers who test spend more time programming moved to Programmers who write tests get more time to program: Hopefully removed ambiguity in title

2008-11-15T21:36:55Z

Programmers who test spend more time programming moved to Programmers who write tests get more time to program: Hopefully removed ambiguity in title

←Older revision

Revision as of 21:36, 15 November 2008

Jhannes: Added common footer

2008-11-15T21:32:25Z

Added common footer

←Older revision		Revision as of 21:32, 15 November 2008
Line 14:		Line 14:

	May you achieve fewer bugs and spend all your days programming happily in a well-designed system!		May you achieve fewer bugs and spend all your days programming happily in a well-designed system!
		+
		+	By [[Johannes Brodwall]]
		+
		+	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