Renaming Unit Tests
Renaming Unit Tests(Note that RonJeffries et al now prefer the term ProgrammerTest to UnitTest.)
moved from UnitInUnitTestIsntTheUnitYouAreThinkingOf?
So, what alternative names might there be, and what inferences might they invite?
Alternative names:
How about CodeObjectsOutsideIn? When I first read about XP, I knew that UnitTests where just this: A way to create objects that make sense to the user of the object, not the developer of that object. The code to actually exercise the object is an added bonus to prove that the interface does, indeed, do what you'd expect as a user of that object. -- JeffPanici
How about SelfTestingSpecification?? (Which can be conveniently abbreviated to UnitTest, obviously ;-) Or maybe AutoSpec for 'automated specification'? Or maybe UnitSpec? Any thoughts?
I don't understand: yes, writing UnitTests has to do with a lot more than just testing code, but XP uses those UnitTests hundreds or thousands of times each to test code. So running UnitTests is squarely a matter of testing.
Exactly: Running the XP UnitTests, after making some change, is testing. But writing the UnitTests before writing the code (CodeUnitTestFirst) is not testing - you don't have anything to test yet. So what is it that you're doing when writing the tests, given that you're not testing?
Are you writing executable specifications/requirements to verify an emergent design?
moved here from XpVsStandardDefinitionOfUnitTest
Why don't we just say DeveloperTests and CustomerTests, that's what we mean isn't it. DeveloperTests? are there to help the developers build the and change the system safely. Customer tests are there to let the customers accept changes to the system safely.
DeveloperTests include low level UnitTests up through subsystem and system tests. The point being that they must always pass because they specify the intent of the developers. If they fail the intent is confused and the developers don't know what they are building.
CustomerTests don't have to all pass until the system is ready to be accepted because the Customers requirement doesn't have to be met until the release. CustomerTests on a released system must always pass because they specify the requirement of the customer. If they fail the system does not meet the requirement. -- TomAyerst
Moved from UnitInUnitTestIsntTheUnitYouAreThinkingOf?
So, an Xp UnitTest is really an ExecutableSpecification??
Well, I suppose you could call it that, since it's executable and it's also a specification, but it's not what's usually meant by that term. Note that the UnitTest isn't executable until you've compiled the thing it tests.
I'm familiar with a specification language developed by DanielJackson, called Alloy, in which you can write a specification and then immediately check it with a program that "executes" it in the sense of generating instances of the thing you specified. Then you can figure out whether your spec actually describes the thing you meant. That might sound like a waste, but you'd be surprised how many things it catches. And, you can do it quite incrementally. "Specify a little; check a little" as they say in Music Man.
Why would you want to call a UnitTest an executable specification anyway, just so you can crank out seven extra syllables? -- WaldenMathews
Does the term driver do anything for y'all? I gather the point of the harness is not to test the code, but to run the code while you are developing it. Thus, it drives the method (by calling it).
Drive, drive, drive, ... DrivingMetaphor???
I use the phrase "Progression Tests" for XP UnitTests - since we write the tests first, when the tests are satisfied we are making progress towards delivering business value requested by the customer. Also, the phrase is sufficiently close to the old faithful "Regression Tests" that people where I work grasp pretty quickly that these tests should always run successfully. -- Anthony Lauder
I'm curious, could a "UnitTest" simply be a subset of an "Acceptance Test"?
My idea of UnitTests is currently resting on something like testing that the class in question adequately fulfills its responsibilities. Hence, you write it first to determine what it will be responsible for, then write the code to handle that responsibility, then write the next test, etc... In some ways, this is very similar to an Acceptance Test, which is written before the full functionality it is testing for is written in the full program.
In essence:
I think the term "UnitTest" actually describes the concept quite well: It's a test for a unit. I suppose it might be argued that the name is not descriptive enough, since it doesn't make it obvious that these tests are normally to be written prior to the implementation. Other than that, though, I think the name is fine.
Moved from UnitTest
So, based on MichaelHill's comments regarding the purpose of UnitTests and RonJeffries's comments in the opener, we should consider renaming UnitTests ProgrammerTests or mobility tests?
-- BilKleb
Moved from UnitInUnitTestIsntTheUnitYouAreThinkingOf?
Since the beginning of this page says that this is a philosophical page, then I would like to add my philosophical two cents.
Over the past few years that I have been participating on Wiki, my philosophy about software has changed. Thanks to WardAndKent et al, I don't care anymore if the code I write is correct; I don't care anymore if the way I write code is correct. Now I care if the code I write works, and if the way I write code works.
Likewise, it doesn't concern me anymore if the name UnitTest is correct or not; it concerns me if the name UnitTest works. The name UnitTest works for me.
One of the reasons the name works for me is what I use unit tests for. I don't really know what Kent had in mind about unit tests, but here is what I use them for:
5% to help me define what I want or wanted. 15% to help show me that what I wrote today works. 80% to help show me that what I wrote today didn't break what I wrote last November.-- StanSilver
Honestly, this page title suggests that XP misuses the term "UnitTest." Or at least it's confusing. That's unfortunate. Clarity is important. Any patching of the concept here isn't really as helpful as a clearer name. RefactorMercilessly XP until it's the simplest!
It does give that impression at first. Could it be that the Unit is still the same Unit and it's the Test that's a different Test?
If the testing experts (and others) are to be believed, then XP does misuse the term "Unit Test". That's not ideal, but at least, if we are explicit about it we might avoid some pointless arguments.
I propose some variant of "Expectation", because thats what it is, the codified form of what the programmer expects of his code. This would make it UnitExpectations? if we stay with the "Unit" or ProgrammerExpectations? if we focus on the programmer. One might also use FunctionalExpectations? or ExecutableExpectations?, but I think that is redundant, all code is functional and executable after all. -- GunnarZarncke
My argument with the term "Unit Test" is that I really do not want to write tests at the class level. I want my tests to be as architecture independent as possible so that I have the widest range of freedom to refactor without changing the tests. Defining the classes that I will use prior to coding seems antithical to having an emergent architecture and I dislike having to change tests and code simultaneously.
This is not a plea to go to pure black box testing either. It is usually not efficient to test through the user interface all the way through to the database. Vairous test insertion points and test stubs are needed to write the tests in the most efficient manner.
Write the tests to describe the expected behavior and let the class architecture fall out as needed.
Then don't use the term that way. My unit tests test methods, not classes. I don't define classes before coding. I start with a single failing test and write a method (and class) to make it pass. My class architecture grows to meet the tests. -- EricHodges
The issue is that I must work with other people. Other people do tend to define unit tests as being class based and see the tools that generate a shell with test calls based on an existing class. This immediately leads to confusion about how tests can be written first. Also, in somewhat circular arguments, I've had senior developers tell me that unit tests must be written at the class level, but then not write them because (paraphrase) it is too much work and not really needed at that level. It is quite unfortunate that when "unit test" was first applied to object oriented programs, unit was defined at the class level. The approach taken for test first design is probably closer to the definition of unit test in procedural languages, but the fact is the definition of unit tests are per class tests is common. The term "unit test" makes communications much more difficult. (As an aside, it looks like we are perfectly in synch in how test first should be applied, I think we are just discussing the significance of the term used.) -- WayneMack
Fortunately (I suppose) I work with people who have few preconceptions about what "unit test" means. From my first exposure to the term (via XP's test driven approach) I've never seen it defined as "class based". I've seen the sort of tools you're talking about, but I avoid them. My unit tests usually end up organized by the classes they test, but that's just a matter of convenience. From my perspective your trouble with the term may be localized to your environment. -- EricHodges
EditText of this page
(last edited November 9, 2005)
or FindPage with title or text search