Write Tests for People - Revision history

Kevlin at 09:36, 17 August 2009

2009-08-17T09:36:51Z

←Older revision		Revision as of 09:36, 17 August 2009
Line 1:		Line 1:
-	You are writing automated tests for some or all of your production code. Congratulations! You are writing your tests before you write the code? Even better!! Just doing this makes you one of the early adopters on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "~~For whom~~ am I writing the tests?" If the ~~anwser~~ is "For me, to save me the effort of fixing bugs." or "For the compiler so they can be executed!" then the odds are you aren't writing the best possible tests. So '''who''' should you be writing the tests for? For the person who's trying to understand your code.	+	You are writing automated tests for some or all of your production code. Congratulations! You are writing your tests before you write the code? Even better!! Just doing this makes you one of the early adopters on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "Whom am I writing the tests for?" If the answer is "For me, to save me the effort of fixing bugs" or "For the compiler, so they can be executed" then the odds are you aren't writing the best possible tests. So '''who''' should you be writing the tests for? For the person who's trying to understand your code.

	Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s):		Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s):
-	# describe the preconditions that must be satisfied,
-	# illustrate how the software is invoked
-	# describe the expected results.

-	~~Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of~~ the ~~tests in question,~~ be ~~able to see what causes~~ the software ~~to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test~~ is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls (the Extract Method refactoring is your best friend.) And make sure you give each test a meaningful name that describes the particular usage scenario so the test reader doesn't have to reverse engineer each test to understand what the ~~various scenarios are.~~	+	# Describe the preconditions that must be satisfied
		+	# Illustrate how the software is invoked
		+	# Describe the expected results

-	It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned ~~about the~~. Listen carefully to what they say~~; if~~ they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely ~~because~~ you weren't very clear. (Go ahead and reverse the roles by reading their tests!)	+	Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls — the Extract Method refactoring is your best friend. And make sure you give each test a meaningful name that describes the particular usage scenario so the test reader doesn't have to reverse engineer each test to understand what the various scenarios are.
		+
		+	It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned. Listen carefully to what they say. If they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely that you weren't very clear. (Go ahead and reverse the roles by reading their tests!)

Gmkayaker at 01:51, 9 August 2009

2009-08-09T01:51:12Z

←Older revision		Revision as of 01:51, 9 August 2009
Line 9:		Line 9:

	It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned about the. Listen carefully to what they say; if they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely because you weren't very clear. (Go ahead and reverse the roles by reading their tests!)		It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned about the. Listen carefully to what they say; if they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely because you weren't very clear. (Go ahead and reverse the roles by reading their tests!)
		+
		+
		+	by [[Gerard Meszaros]]
		+
		+	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

Gmkayaker at 05:32, 8 August 2009

2009-08-08T05:32:23Z

←Older revision		Revision as of 05:32, 8 August 2009
Line 6:		Line 6:
	# describe the expected results.		# describe the expected results.

-	Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls (the Extract Method refactoring is your best friend.) And make sure you give each test a meaningful name that describes the particular usage scenario.	+	Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls (the Extract Method refactoring is your best friend.) And make sure you give each test a meaningful name that describes the particular usage scenario so the test reader doesn't have to reverse engineer each test to understand what the various scenarios are.

	It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned about the. Listen carefully to what they say; if they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely because you weren't very clear. (Go ahead and reverse the roles by reading their tests!)		It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned about the. Listen carefully to what they say; if they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely because you weren't very clear. (Go ahead and reverse the roles by reading their tests!)

Gmkayaker at 05:31, 8 August 2009

2009-08-08T05:31:38Z

←Older revision		Revision as of 05:31, 8 August 2009
Line 6:		Line 6:
	# describe the expected results.		# describe the expected results.

-	Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls (the Extract Method refactoring is your best friend.)	+	Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls (the Extract Method refactoring is your best friend.) And make sure you give each test a meaningful name that describes the particular usage scenario.

	It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned about the. Listen carefully to what they say; if they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely because you weren't very clear. (Go ahead and reverse the roles by reading their tests!)		It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned about the. Listen carefully to what they say; if they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely because you weren't very clear. (Go ahead and reverse the roles by reading their tests!)

Gmkayaker at 05:29, 8 August 2009

2009-08-08T05:29:52Z

←Older revision		Revision as of 05:29, 8 August 2009
Line 1:		Line 1:
-	You are writing automated tests for some or all of your production code. Congratulations! You are writing your tests before you write the code? Even better!! Just doing this makes you one of the early adopters on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "For whom am I writing the tests?" If the anwser is "For me, to save me the effort of fixing bugs." or "For the compiler so they can be executed!" then the odds are you aren't writing the best possible tests. So ~~who~~ '''~~should~~''' you be writing the tests for? For the person who's trying to understand your code.	+	You are writing automated tests for some or all of your production code. Congratulations! You are writing your tests before you write the code? Even better!! Just doing this makes you one of the early adopters on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "For whom am I writing the tests?" If the anwser is "For me, to save me the effort of fixing bugs." or "For the compiler so they can be executed!" then the odds are you aren't writing the best possible tests. So '''who''' should you be writing the tests for? For the person who's trying to understand your code.

	Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s):		Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s):

Gmkayaker at 05:28, 8 August 2009

2009-08-08T05:28:56Z

←Older revision		Revision as of 05:28, 8 August 2009
Line 1:		Line 1:
-	You are writing automated tests. Congratulations! Just doing this makes you ~~part~~ of the early ~~adoptions~~ on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "For whom am I writing the tests?" If the anwser is "For me, to save me the effort of fixing bugs." or "For the compiler so they can be executed!" then the odds are you aren't writing the best possible tests. So who '''should''' you be writing the tests for? For the person who's trying to understand your code.	+	You are writing automated tests for some or all of your production code. Congratulations! You are writing your tests before you write the code? Even better!! Just doing this makes you one of the early adopters on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "For whom am I writing the tests?" If the anwser is "For me, to save me the effort of fixing bugs." or "For the compiler so they can be executed!" then the odds are you aren't writing the best possible tests. So who '''should''' you be writing the tests for? For the person who's trying to understand your code.

	Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s):		Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s):

Gmkayaker at 05:27, 8 August 2009

2009-08-08T05:27:12Z

←Older revision		Revision as of 05:27, 8 August 2009
Line 1:		Line 1:
-	You are writing automated tests. Congratulations! Just doing this makes you part of the early adoptions on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "For whom am I writing the tests?" If the anwser is "For me, to save me the effort of fixing bugs." or "For the compiler so they can be executed!" then the odds are you aren't writing the best possible tests. So who should you be writing the tests for?	+	You are writing automated tests. Congratulations! Just doing this makes you part of the early adoptions on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "For whom am I writing the tests?" If the anwser is "For me, to save me the effort of fixing bugs." or "For the compiler so they can be executed!" then the odds are you aren't writing the best possible tests. So who '''should''' you be writing the tests for? For the person who's trying to understand your code.
		+
		+	Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s):
		+	# describe the preconditions that must be satisfied,
		+	# illustrate how the software is invoked
		+	# describe the expected results.
		+
		+	Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls (the Extract Method refactoring is your best friend.)
		+
		+	It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned about the. Listen carefully to what they say; if they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely because you weren't very clear. (Go ahead and reverse the roles by reading their tests!)

Gmkayaker: New page: You are writing automated tests. Congratulations! Just doing this makes you part of the early adoptions on the leading edge of software engineering practice. But are you writing good tests...

2009-08-08T05:15:15Z

New page: You are writing automated tests. Congratulations! Just doing this makes you part of the early adoptions on the leading edge of software engineering practice. But are you writing good tests...

New page

You are writing automated tests. Congratulations! Just doing this makes you part of the early adoptions on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "For whom am I writing the tests?" If the anwser is "For me, to save me the effort of fixing bugs." or "For the compiler so they can be executed!" then the odds are you aren't writing the best possible tests. So who should you be writing the tests for?