Talk:Unit testing

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
??? This article has not yet received an rating on the importance scale.

Contents

[edit] History

I'd like to see information about the history of formal unit tetsing, when did it come about, for what technologies, when was it popularised etc???

Ian —Preceding unsigned comment added by 82.10.239.38 (talk) 19:26, 10 February 2008 (UTC)

[edit] Unit tests without a framework

This was written By SangameswaraRao Udatha

Writing a test cases using a framework such as JUnit is common. One can also write programs that test other programs without using a framework. However unit test does not always mean writing test case programs. Unit tests can be manual too.

Unit test are tests done by programmers to make sure a low level code works as he intended.

" When basic, low-level code isn't reliable, the requisite fixes don't stay at the low level. You fix the low level problem, but that impacts code at higher levels, which then need fixing, and so on." - Andy Hunt and Dave Thomas

Erm... so what do you want to do? — Edward Z. Yang(Talk) 21:20, 25 April 2006 (UTC)

[edit] Regression

Should 'regression' point to the page on 'regression testing'?

[edit] Extreme programming's use of unit tests

"Extreme Programming and most other methods use unit tests to perform white box testing."

Maybe I'm just splitting hairs here. But XP and TDD use unit tests more as black box. From an outside point of view, you figure how you want to use the code. Then, you write the code that makes it happen. White box implies looking at the code and determining test cases to test it. Maybe this is a gray area (pun partially intended.) DRogers 18:39, 14 September 2006 (UTC)

It's more of a terminology issue. From what I've heard, eXtreme Programming founded Test-Driven Development, and advocates under-the-hood testing to make sure everything gets covered. — Edward Z. Yang(Talk) 22:57, 14 September 2006 (UTC)
Well, it's under-the-hood of the project, but each module is still a black box as far as the tests are concerned... right? I guess the text refers to "project white box testing", since the tests "see" the inner modules. --Pedro 23:57, 4 October 2006 (UTC)

[edit] Removed links

These are all by the same author. — Edward Z. Yang(Talk) 23:07, 12 October 2006 (UTC)

As the author, I don't see the problem in that. these are quality links, to different sites. Why did you remove them? Roy Osherove.


[edit] Techniques: minor cleanup requested

The first two paragraphs of the section, "Techniques" don't run together. The IEEE standard for Software Unit Testing, albeit dated, isn't foreign to what occurs today for unit testing (a practice that is most decidedly automated). Perhaps the text regarding the standard should be removed altogether? .digamma 00:08, 28 October 2006 (UTC)

Or if the section is fine as is remove the cleanup-requested banner..digamma 22:27, 31 October 2006 (UTC)
I have cleaned this section up - hopefully it is less confusing now. Cleanup tag removed.--Michig 14:42, 24 November 2006 (UTC)

[edit] Clarification requested re role of mock objects in 'separation'

In the lead we currently have the following clause: "constructs such as mock objects can assist in separating unit tests". Could someone clarify what this means? Are we separating unit tests from each other, or from other 'modules' in the system. I guess this is something to do with being able to run unit tests on modules in isolation from other possibly buggy modules, but this isn't clear (at least to me) from the way it is currently worded. Stumps 15:18, 24 November 2006 (UTC)

While this article perhaps does not make this clear, the linked Mock object article expands on this. Does it need any further explanation in this article, or would this be unnecessary duplication?--Michig 15:37, 24 November 2006 (UTC)
Thanks. I've tried to make the lead section a little clearer, without unnecessarily duplicating information from the mock object article. 83.5.247.168 06:37, 25 November 2006 (UTC) [oops ... wasn't logged in! Stumps 06:38, 25 November 2006 (UTC)]

[edit] Code Hygiene

The section on facilitating change touches on this obliquely, but I think that code hygiene is a separate goal. Most people have worked on codebases that are either deteriorating or have already deteriorated, with the dreaded "don't touch that, nobody understands it" sections. —The preceding unsigned comment was added by 131.107.0.73 (talk) 18:38, 18 January 2007 (UTC).

[edit] whats the point in this sentence: The IEEE[1] prescribes neither an automated nor a manual approach.

If the IEEE prescribes neither an automated nor a manual approach, then why even mention it? My dog prescribes neither an automated nor a manual approach. —The preceding unsigned comment was added by Ronnystalker (talk • contribs) 09:16, 7 April 2007 (UTC).

I think the point that the IEEE doesn't favor one over the other is much more significant than the fact that your dog doesn't favor one over the other. The IEEE is much more authoritative. DRogers 00:26, 8 April 2007 (UTC)

I think that's a much better way of putting it. Perhaps the sentence "The IEEE[1] prescribes neither an automated nor a manual approach." should be changed to "The IEEE[1] does not favour one approach over the other." I'm a newbie so I'm not confident enough to go editing pages (especially code that has a little [1] in it, in a topic that i know little about). But, I do know that I stumbled over that sentence as a reader. E.g "prescribing neither something nor another" seems a little odd to me. Ronnystalker 06:03, 8 April 2007 (UTC)

Ok, I'll make that change. DRogers 14:58, 8 April 2007 (UTC)

[edit] Test Centric Languages

I think the critique of all existing test frameworks as not being built in to the language is both a bit brutal and perhaps a marketing point for the D programming language, which was referenced without any evidence that it improved productivity.

  • Java's TestNG adds tests to the language through annotations, instead of procedural code.
  • functional languages (Lisp, scheme, haskell) can be good for testing when their functions are side effect free -its very easy to test functions when their whole output is visible and testable.
  • the PLUnit test framework for prolog uses prolog clauses as test statements, which is incredibly high level.

The current content should be rolled back (or backed up with auditable claims), and/or the area broadened to look at other languages. SteveLoughran 10:48, 17 April 2007 (UTC)

The statement referring to the D programming language was inserted on 20:55, 20 July 2004 by 24.16.52.122, who also added similar irrelevant pro-D comments to a number of other Wiki pages. I suggest it be removed. jon 11:48, 14 May 2007 (UTC)

[edit] Testing Abstract Classes

I can understand separating Unit Testing from specific languages, but "... which may be a[n] ... abstract class or ..." seems a little unusual since few languages allow instantiation of abstract classes. Or is this to imply that an abstract class would be tested through a derived class? How would you test an abstract class (generally no code) in an automated way? —The preceding unsigned comment was added by Mweddle (talk • contribs) 16:02, 16 May 2007 (UTC).

I think the point is that an abstract base class is something you might want a unit test for - abstract classes can contain code, however they can't be directly instantiated. To instantiate one for the purposes of testing, you would need to create an instance of a concrete derived class. If one isn't readily available, then you might define a dummy subclass purely for the purposes of testing. jon 16:11, 21 May 2007 (UTC)

[edit] Definition of Unit

I believe the defintion of "unit" in the first paragraph is incorrect. In object oriented programming a unit should be the method, not the class. Not only is a method the smallest testable part but from a practical point of view, testing at that level reduces the tendency to do functional black box testing and encourages making sure each line of code does what it was intended to do. Sspiro 18:07, 12 September 2007 (UTC)

[edit] Alternative Terminology

Some, me among them, have begun to call XP's version of unit testing microtesting. I'm wondering if the text below is appropriate to add to the article under the Extreme Programming sub-head:

A move has been made in the XP world to re-christen the practice of unit testing as microtesting. The case is made that unit testing already has a rich pre-XP meaning that incorporates many un-extreme practices, and that a more precise term is needed. The movement has gained a very small amount of ground. A few hundred XP practitioners and one XP consultancy (Industrial Logic, Inc).

This is a fact, especially if you emphasize 'very small'. There are probably only a few hundred people who have adopted the term, and It is an attempt to be NPOV. The mentioned link self-proclaims its adoption.

  1. Is this a valid citation?
  2. Am I a spammer because, in fact, I invented the term?
  3. Am I a spammer because, in fact, I work for said company, and convinced them of the need for the name change?
  4. Am I being foolish to think that one can (or should) say that 'the movement has gained a very small amount of ground' on the basis of the few hundred people and dozen or so corporations who use the term?
  5. Am I going to live in fear forever???

No. In fact, I'm going to just leave this note right here and let someone else decide what to do with this data point. Cheers! GPa Hill 09:03, 22 September 2007 (UTC)

[edit] Cited content added

I added some cited content from Albert Savoia (who has joined forces with Kent Beck, the father of JUnit). I apologize for the repeated versions that I committed, but I struggled to get the note formatting to work. Apparently, the citation template doesn't like extraneous spaces. —Preceding unsigned comment added by MickeyWiki (talk • contribs) 17:47, 29 November 2007 (UTC)

[edit] How much code it takes

  • for every line of code written, programmers often need 3 to 5 lines of test code

Maybe I'm doing something wrong, but I don't find I need this much test code. I've been running about 1 line of test per line of production code for the last few years.

I don't test everything that is testable. I only make sure that the program passes a few key tests. Like if I wrote a program to convert between Centigrade and Fahrenheit, I would write 4 test cases for each conversion:

  • -40C = -40 F
  • 0C = 32 F (freezing/melting point of water)
  • 20C = 68 F (room temperature)
  • 100C = 212 F (boiling point of water)

Of course, if you consider the only "real" line of code to be the conversion itself:

centigrade = (fahrenheit - 32) / 1.8

... then maybe you do need 3 to 5 lines of code. But I count every non-blank line, so this routine has 4 lines.

float toCentigrade(float fahrenheit) {

    float centigrade = (fahrenheit - 32) / 1.8;

    return centigrade;
}

Golly, I hope this is not WP:Original research. :-) --Uncle Ed (talk) 18:32, 23 January 2008 (UTC)

I believe what Savoia is getting at is that in order to *fully* test one line of code, you need to write 3 to 5 lines of test code. You might apply your own discretion and not test every conceivable scenario. Heck, it wouldn't be cost effective to do so. He's trying to illustrate the complexity of properly testing code. Covering all outcomes of all decision points is costly (which he why he has become a champion for what Michael Feathers calls "characterization tests").MickeyWiki (talk) 00:21, 24 January 2008 (UTC)

Well, if that's some published author's view, then it should go into the article whether I agree or not - obviously! :-)

I'll dig through the textbooks and articles I learned refactoring and unit testing from. Maybe this will shed some light on the proportion question. But the focus was not on "testing lines of code" but on "making sure the program works".

The thing being tested is not code per se, but the functionality of the program. That is why refactoring can work so well, in conjunction with unit testing. We are never testing any particular line of code. Rather, we are testing whether the program gives the right response when you tell it to do something.

We might create an elaborate set of routines with dozens of lines of code, just to pass a one-line test. If that is what it takes. Just this morning, I created an entire new class in Java because of a failing test that was only 4 lines long. That's lopsided in the other direction! --Uncle Ed (talk) 02:53, 24 January 2008 (UTC)

I don't think anybody is always writing tests to target a specific line of code. "3 to 5" is an average. Clearly, you don't need 5 lines to validate a simple assignment. But, you might need 30 to test one of the those cases that's "lopsided in the other direction".
It's an average - and it doesn't mean you're going to write 3,000 to 5,000 lines of code to test a 1,000 line module. Shooting for 100% code coverage is not cost effective. Some testing is most appropriately deferred to the QA team. Developers get paid big bucks to cut corners - their skills come in knowing exactly what corners can safely be cut (i.e., what doesn't really need a test case).
Consider this: a simple if-block like "if (i > 10) then...". You need to write two tests - one where the expression is true, and one where it is false. What if the if-block contains another if-block with a simple boolean expression? What about multiple if-blocks? The number of paths through the code quickly multiplies.
Find a tool that'll meaure the McCabe Cyclomatic Complexity of your code. You'll be suprised how truly complex some simple looking code segments really are!
This is all true even in the TDD environment you describe. Whether you write tests first or code first, the code coverage challenges are the same.MickeyWiki (talk) 19:06, 24 January 2008 (UTC)

Yeah, it sounds like you're talking about "code coverage" - which is the angle from which ABC, Inc. was exploring test software. I'm more interested in finding out whether the program does its job correctly. It's a subtle difference. --Uncle Ed (talk) 17:28, 25 January 2008 (UTC)