(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: * UnitTest * ProgrammerTest * CodeObjectsOutsideIn * SelfTestingSpecification * DeveloperTest and CustomerTest * ExecutableSpecification * CodeDriver * ProgressionTest (compare with RegressionTest) * UnitExpectations ---- How about CodeObjectsOutsideIn? When I first read about XP, I knew that UnitTest''''''s 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 '''A''''''utoSpec''' for 'automated specification'? Or maybe '''U''''''nitSpec'''? Any thoughts? ''I don't understand: yes, writing UnitTest''''''s has to do with a lot more than just testing code, but XP ''uses'' those UnitTest''''''s hundreds or thousands of times each to test code. So ''running'' UnitTest''''''s is squarely a matter of testing.'' Exactly: Running the XP UnitTest''''''s, after making some change, is testing. But '''''writing the UnitTest''''''s''''' 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 DeveloperTest''''''s and CustomerTest''''''s, 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. DeveloperTest''''''s include low level UnitTest''''''s 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. CustomerTest''''''s 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. CustomerTest''''''s 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???'' : You're Driving the tests? : And the tests drive your code? The tests are the control mechanism that lets you drive the code where you want it to go (and let it tell you if it doesn't want to go there? : ''Hmmm...'' ---- I use the phrase "Progression Tests" for XP UnitTest''''''s - 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 UnitTest''''''s 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: * The full program is a class whose UnitTest''''''s ''are'' the program's acceptance tests; * Each little class is a full fledged program whose UnitTest''''''s ''are'' the class' acceptance tests. -- WilliamUnderwood ---- 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. : ''But '''''writing the UnitTest''''''s''''' before writing the code (CodeUnitTestFirst) '''is not testing''' - you don't have anything to test yet.'' : If that tiny technical detail bothers you, just create an empty class to apply the UnitTest to; that way, you can test the (inane) unit right from the very beginning! In essence, what you're doing is creating a test for a unit - fleshing out the unit interface and semantics in the process - and then making the test pass by implementing the unit correctly. The UnitTest is then run periodically to make sure the unit is still working as expected. The ''"but you don't have anything to test yet"'' argument is simply wrong: You can still write the test. -- DanielBrockman ---- ''Moved from UnitTest'' So, based on MichaelHill's comments regarding the purpose of UnitTest''''''s and RonJeffries's comments in the opener, we should consider renaming UnitTest''''''s ProgrammerTest''''''s 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. - WayneMack ''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'' ---- CategoryTesting