Talk:Test-driven development

message: The "Limitations" section says that TDD "is currently immature". I don't understand what is meant by that.
::Maybe a better term would be "Premature for the guy who wrote the Limitations section". I think we can all agree it's not for everyone. Slackmaster K 18:49, 18 July 2008 (UTC)
replies: text: I would like to hear your thoughts on testing GUIs. Are you talking about abstracting functionallity away from the GUI into a business logic layer, and just using the GUI as a thin interface layer on top? If so, technically you still aren't testing the GUI. Testing GUIs and graphics in general just isn't very feasible right now. Computers get lost in not "seeing the forest for the trees". One can use tests to check pixel values on the screen, but what good is it if the test can't determine *what* the picture shows. capnmidnight 16:18, 30 April 2006 (UTC)
replies: text: I partially agree.  Regardless of your level of abstraction, the Event Handlers are almost always in the inline code, scripting, or code behind. IMHO "GUI testing" is a test of whether or not the GUI reacts as expected.  For example, if clicking a button instantiates an object in the DAL and it results in a NullReferenceException, it could be a GUI bug (i.e. Session cleared between Postbacks) or a DAL bug (i.e. no constructor, returned null, etc). Slackmaster K 18:55, 18 July 2008 (UTC)

text: Are we talking about testing the widget set used by others to write their apps, or about testing app code written on top of the widget set? Testing the widgets in themselves is IMO doable using mocks for their clients, plus bitmap comparison for visual appearance. Testing their clients is similarly doable by mocking he widgets. I too used to think that UI unit testing is not possible. However, I'm not thinking that way anymore, since I got a better understanding of what unit testing actually is. Testing an application's oerall appearance, including events generated by widgets and layout is not unit testing, it's integration testing at its best - it tests several components across at least two layers (your UI code and the widget library you use) at once. Writing a test that actually exercises the entire call stack, from the click on the button down to the persistence layer, is even farther away from unit testing. When unit testing the button widget, you're only interested that a click generates a click event. When unit testing your UI handler code, you don't really care from where the click event comes, you just want to see that if it is received, it is correctly routed further downstream. The question, IMO, isn't whether TDD-ing for UI development is possible, but whether it makes sense. I mean, I don't use TDD on glue code, and most UI code should be glue code, IMO.  — Preceding unsigned comment added by 212.146.95.34 (talk) 10:46, 14 June 2013 (UTC)

text: The only advice I know is, "Carefully, very carefully". I have become aware how 'precious' TDD tests are, because unless you are willing to scrap the whole piece of code and start TDDing again, they can never be replaced. Not everyone you may work with will be aware of that as they maintain the module! Tools like NCover do not solve the problem - a regex test may get used by the tests, but not necessarily in every boundary case that is important.  I wonder, do we need something on the joys and limitations of NCover and its brethren here? --Nigelj (talk) 19:38, 26 August 2009 (UTC)
thread_title: Limitations section

message: The link to "Test-driven Development using NUnit" at in the References is non-functional in my browser (Firefox 1.0, Windows 2000). I suggest this link be eliminated, and along with it the Jason Gorman vanity page as non-encyclopedic. --Ghewgill 18:35, 13 Jan 2005 (UTC)
replies: text: Works fine on my Linux box with Firefox.  He probably didn't have a pdf viewer installed. --Nigelj 20:34, 30 August 2006 (UTC)

text: I have tagged it as dead. Walter Görlitz (talk) 14:38, 30 November 2019 (UTC)
thread_title: non-functional link

message: A merge with Test Driven Development is in order.  Actually that article frames the generic issues better, though it's a short stub, and this article seems  (in the section Test Driven Development Cycle) to imply that there's a proper-named methodology here.
:Ummm, the Test Driven Development page just is re-direct to this page: they are the same article.--Nigelj 20:31, 30 August 2006 (UTC)
thread_title: Merge

message: Please, Who is the author of first article about "Test Driven Development"??? Who defends "Test Driven Development"? Etc...
I think it would be very helpful for everyone is researching about it.
--200.144.39.146 17:16, 10 March 2006 (UTC)
replies: text: From the article: "the book Test-Driven Development by Example [Beck, K., Addison Wesley, 2003], which many consider to be the original source text on the concept in its modern form."--Nigelj 20:31, 30 August 2006 (UTC)
replies: text:  It predates 2003. We used the phrase in Java Development with Ant in 2002, and took it from one of Kent's earlier XP books. I think I first saw it in 2000, associated with JUnit work by Kent and Erich Gamma. SteveLoughran 10:41, 17 April 2007 (UTC)
thread_title: Where is "Test Driven Development" from?

message: I read Tester Driven Development and it seems appropriate to move it into a "criticisms" section of this page.  --Chris Pickett 22:32, 30 November 2006 (UTC)
replies: text: No, I think that it is a play on similar words, but as a concept it is entirely different.  I've never heard what that article describes called 'tester driven development', but I have heard it called 'feature-creep', 'buggy spec' etc.  It's an example of one way a project manager can begin to lose control of the project, not anything to do with the development methodology the developers may or may not be using to produce the actual code. --Nigelj 22:04, 30 November 2006 (UTC)
replies: text: I realize that "Tester Driven Development" is not the same thing as TDD.  But it seems to me like this anti-pattern might actually describe TDD done badly.  "It refers to any software development project where the software testing phase is too long."---clearly that includes TDD, since you can't get "longer" than "since before the project begins"! :)  Well, at the very least, there should be a disambiguation page or "not to be confused with" bit or something, so that people looking for Tester Driven Development when they mean TDD don't get the wrong impression.  --Chris Pickett 22:32, 30 November 2006 (UTC)
replies: text: Tester-Driven Development is clearly a pun on TDD, but a different concept. I think Tester-Driven-Development could be pulled into an anti-patterns in testing article, which could include other critiques of TDD, and of common mistakes in testing (like not spending any time on it). SteveLoughran 10:42, 17 April 2007 (UTC)
thread_title: Merge with Tester Driven Development

message: :Automated testing may not be feasible at the limits of computer science (cryptography, robustness, artificial intelligence, computer security etc).
What's the problem with automated testing of cryptography? This sentence is weird and needs to be clarified. — ciphergoth 11:08, 19 April 2007 (UTC)
replies: text: Automated testing is pretty tricky today with testing that a web site looks ok on mobile phones, especially if its a limited run phone in a different country/network from where dev team is; I'd worry more about that than AI limitations. Security is a hard one because one single defect can make a system insecure; testing tries to reassure through statistics (most configurations appear to work), but can never be used to guarantee correctness of a protocol or implementation. 'Robustness' is getting easier to test with tools like VMWare and Xen...you can create virtual networks with virtual hardware and simulate network failures. SteveLoughran 21:24, 19 April 2007 (UTC)
thread_title:  Limits of computer science 

message: I'm pretty unimpressed with the quality of half the external links here...they primarily point to various blog entries in the .NET land. Those aren't the in-depth references that wikipedia likes to link to. I've gone through and (a) cut out anything that wasnt very educational or required logins to read and (b) limited links to one per blog. Furthermore I'm not convinced by the referenced articles that VS2005 is capable of test-first development, at least if you use the built in framework, but I left the articles there in.
Given that TDD originated in Smalltalk and Java, I'd expect to see some more there. Here's some options
* Push all product listings to the separate List of unit testing frameworks
* Split stuff up by .NET, Java, Ruby, other platforms, and try and keep coverage of all of them.
* Create separate pages for testing in Java, testing in .net, where we can cover the controversy (The junit4 problem, testng vs junit, NUnit versus the MS Test tools...)
If there is value in all the remaining blog entries, this content could be used as the inspiration for a better wikipedia article.  —Preceding unsigned comment added by SteveLoughran (talk • contribs) 20:46, 17 January 2008 (UTC)
replies: text:  The links havent improved much. Unless anyone else wants to, I'm going to take a sharp knife to the links. Those that make good articles to reference, they should become references. Those that dont get cut. I don't want to impose a 'no blog' rule because it is how some of the best TDD proponents get their message out. But we have to have high standards: it has to be something on the class of Martin Fowler's blog to get a mention. SteveLoughran (talk) 21:32, 25 May 2008 (UTC)
replies: text:  I've just moved some of the links around and purged any that weren't current or particularly good. Another iteration trimming out the .NET articles is needed. SteveLoughran (talk) 22:12, 25 May 2008 (UTC)
replies: text: I cleaned out quite a lot of them. Let's start fresh and add back valuable stuff one at a time as needed (if in fact any are needed). - MrOllie (talk) 01:10, 13 June 2009 (UTC)
thread_title:  Low Quality external links 

message: In this edit an anonymous user at 65.57.245.11 completely re-wrote the Code visibility section without comment or discussion. S/he introduced a discussion of black-box, white-box and glass-box testing. As far as I know, these concepts relate to testing, but are quite alien to test-driven development.  In my experience, if you are unit-testing as you develop, you often have to test the details of code whose function is vital, but that will end up 'private' in the final deployment.
I have been re-reading some of 'TDD by example' by Kent Beck, but can't find any discussion of these issues. Have other editors got some reputable references that can help us get to the bottom of what should be in this section?  —Preceding unsigned comment added by Nigelj (talk • contribs) 23:04, 25 January 2008 (UTC)
replies: text: I think that the discussion of black-box, white-box and glass-box testing is out of place here as it has no relevance to TDD. In my experience, you have to write tests at potentially every level of the code, depending on your confidence level and therefore the size of the TDD 'steps' that you are taking at the time.  If that means you have to end up making encapsulated members public just to test them, it can ruin the proper encapsulation of the actual design.  That's why I originally wrote this section, as that's important, and there are tricks that help with it that are non-obvious at first.  The section's fairly meaningless now, but now that every entry in WP has to be referenced, I'm afraid I don't have time at the moment to track down references for all that was there before this edit.  It's a shame that the section's currently full of such irrelevant and useless tosh at the moment, though. --Nigelj (talk) 17:21, 26 May 2008 (UTC)
replies: text: Having read it again, it reads like almost academic paper-style definitions of things, apparently not written by a practitioner of TDD; some projects clearly scope test cases to have access to internal state of the classes. As you say, it needs to be massively reworked. We can put the x-references in after. Overall, I'm worried about this article...it seems to have got a bit long and become a place for everyone with a test framework or blog on testing to put a link. If we trim the core text, we'd be making a start at improving it. SteveLoughran (talk) 09:51, 27 May 2008 (UTC)
thread_title:  Code visibility 

message: I can't figure out what this sentence is supposed to mean: "To achieve some advanced design concept (such as a design pattern), tests are written that will generate that design." What does it mean for tests to generate a design concept?  —Preceding unsigned comment added by 203.45.67.213 (talk) 00:52, 5 October 2009 (UTC)
thread_title:  What Does This Mean 

message: "Test fails" and "Test succeeds" appear to be backwards in the flow chart.  Rewriting a test if it succeeds, and writing production code if it fails doesn't make sense.  —Preceding unsigned comment added by 134.167.1.1 (talk) 20:41, 2 December 2009 (UTC)
replies: text: No, it is right. If a new test passes straight away, it isn't going to 'drive' any new code development, so you re-write the test until it needs some new code to be written to make it pass. (This is an unusual requirement, usually a new test fails straight away and you can proceed, but it can happen) Then, you have a failing test and you write new, production code until it passes. (That's the bit where the test 'drives' the development) Then refactor the code, keeping the pass. And then repeat. Red-Green-Refactor. --Nigelj (talk) 20:56, 2 December 2009 (UTC)
replies: text: There is still something that I don't understand in the flowchart. Does the "Clean up code" square corresponds to the refactoring step ? If it is; I think that the first diamond "Check if the test fails" has to be inverted (yes <-> no). Refactor a test should not break it. I think that this flowchart is quiet confusing.Raoulinet (talk) 16:44, 11 December 2012 (UTC)
replies: text: "Clean up code" is the last step in a cycle, and it does refer to the refactoring step. While refactoring, all the tests will probably be run several times, and again afterwards, and it is true that none of these test runs are explicit in the diagram. I guess whoever drew it assumed that, having got that far, re-running the tests will obviously be part of the refactoring process. This is clear in the article text. When you loop back to the top, you are starting a new test cycle and so you start with a new test, that initially fails, to drive the development of some further new functionality, so of course the meaning of the steps have to be the same as they were last time through. --Nigelj (talk) 18:36, 11 December 2012 (UTC)
replies: text:  It's not just refactoring, but that is a large part of it. Otherwise, I agree with Nigelj. --Walter Görlitz (talk) 19:53, 11 December 2012 (UTC)
replies: text:  Thanks. Raoulinet (talk) 07:46, 12 December 2012 (UTC)
thread_title: Flowchart

message: Many articles have a "Criticisms"  section, why Test-Drive-Development doesn't?  —Preceding unsigned comment added by 8.7.228.252 (talk) 22:19, 10 June 2010 (UTC)
replies: text: See WP:STRUCTURE - it is usually best to "fold[] debates into the narrative, rather than distilling them into separate sections", so any ingrelevant, well-sourced criticisms of TDD should be mentioned, as they arise, in the normal text rather than separated out into a "Criticisms"  section. --Nigelj (talk) 08:53, 11 June 2010 (UTC)
thread_title:  Criticisms  

message: What's with the blurry flowchart? Why is it png instead of pure svg?
69.120.152.184 (talk) 02:15, 26 September 2011 (UTC)
thread_title:  Blurry flowchart 

message: Response to: "The material you added to the article was taken from several sources with only minor edits. The reference did also not meet Wikipedia's WP:V policy as one is required to create an account to access the whitepaper. I'm sorry, but I had to remove it all despite how promising it appeared to be. Walter Görlitz (talk) 21:20, 27 November 2012 (UTC)
replies: text: I represent the copyright holder and have submitted a declaration of consent to donate the copyrighted material. Also, you are not required to create an account to access the whitepaper. The access page is merely an optional request for information. Clicking send will take you directly to the whitepaper PDF. I found the WP:V guidelines unclear based on your comment. Although this is not the case, I thought sources that require purchase or membership were acceptable: "Other people should in principle be able to check that material in a Wikipedia article has been published by a reliable source. This implies nothing about ease of access to sources: some online sources may require payment, while some print sources may only be available in university libraries." WP:V --Stephaniefontana (talk) 15:54, 28 November 2012 (UTC)
thread_title:  Recent Additions to "Requirements", "Development Style", and "Fakes, Mocks, and Integration Tests" 

message: Hi,
We received an OTRS id today for the content added in this edit and for content on http://pathfindersolns.com. The content is released as "Creative Commons Attribution-ShareAlike 3.0" (unported) and GNU Free Documentation License (unversioned, with no invariante sections, front-cover texts, or back-cover texts), which is compatible with Wikipedia's license.
If you have any questions, you can leave a note at WP:OTRS/N or my talk page. Thanks, Legoktm (talk) 22:27, 28 November 2012 (UTC)
thread_title:  ConfirmationOTRS|license= for pathfindersolns.com 

message: I some recent edits, I became aware just how much of the present state of this article depends on a single commercial source - Pathfinder Solutions of Wrentham, Massachusetts. I was just about to make some changes, and decided to check what the cited source actually said. I was faced with a webform saying, "Pathfinder Solutions. Download Whitepaper. Before downloading, please tell us a little about yourself." Now I really am upset. It's like a Wikipedia page has been hijacked by a private company who is using it to gather a database of personal information about the editors and readers of this article. I suggest that, to avoid corporate sponsorship of any Wikipedia page, the rest of us work to find replacement references that are actually freely available. --Nigelj (talk) 21:45, 22 January 2013 (UTC)
replies: text: Seems to meet the :WP:SPAMLINK guideline. Remove at will. If you want to leave the content and tag it, that would probably be best. --Walter Görlitz (talk) 21:50, 22 January 2013 (UTC)
thread_title:  Pathfinder Solutions 

message: The sentence, "Use Kent Beck's four rules of simple design", which has two links, requires me to go off site in order to understand the recommendation.  They should instead be listed in the article, if they're that important. KazDragon (talk) 10:02, 26 September 2013 (UTC)
thread_title:  Off-Site Knowledge 

message: This article appears to be in pretty poor shape at the moment.
#Someone had been busy converting sections into bullet point lists, in opposition to WP:PROSE guidelines.
#Most of the worst bits of the text still reference that awful Pathfinder PDF (see comments in two sections above). I think most of that stuff was copy-and-pasted.
#There is a vast amount of how-to style addressing of the reader: "Remove any duplication you can find," "Use Kent Beck's four rules of simple design to guide you," and so on. There are also lots of implied "you's" as the subjects of instructional sentences like, "Move code from where it was convenient..."
There must be a wealth of university-level books on the subject of TDD by now, that we can base better-sourced text on. I'm no longer involved in software development, so I'm not really in the swim as I once was.  --Nigelj (talk) 11:55, 22 May 2014 (UTC)
thread_title:  Pretty poor shape 

message: Hi! This is with reference to your recent reversion of my edit. I had removed some warnings at the top of the Individual Best Practices section because they didn't seem pertinent. I'd like to explain that.
The first warning concerned "How-To" content. The ensuing list is a list of best-practices -- not a step-by-step guide. It's functionally equivalent to saying:
Bread recipes often include
* Water
* Yeast
* Flour
* Salt
Furthermore, this in no way detracts from the content, and given that I personally found it useful, it doesn't seem like it should be flagged for removal or restructure.
The second warning is regarding prose. This is purely stylistic, and I don't think it's appropriate to turn what is essentially a list into prose with useless filler just because some convention somewhere says so. The end result would be harder to read and less useful overall. This doesn't seem to be in alignment with the point of a wonderful resource like Wikipedia.
Please consider reinstating my edit.
Thanks,
Kael.shipman (talk) 16:59, 3 August 2016 (UTC)
replies: text: Removing such tags is supposed to be by consensus.  We need more than one editor's opinion to remove these.  Myself, I'd keep these tags, as the section doesn't follow WP norms, even if the info is correct.  --A D Monroe III (talk) 17:08, 3 August 2016 (UTC)
replies: text:  I too would remove those edits. Oh. I did. Walter Görlitz (talk) 03:43, 4 August 2016 (UTC)
thread_title:  Warnings on "Individual Best Practices" section 

message: Current article version explains main ideas of test-driven development. However it does not contain information about its acceptance and practical relevance for the software development. As already mentioned its links seem to not be updated. It also does not inform about software companies using and teaching TDD. 
Recently one of the TDD practitioners has created a comprehensive web site containing a growing list of companies and teams that practice TDD, http://www.wedotdd.com/ . This site collects information world wide. Actually it is the current who is who list of companies focusing on TDD. For instance it contains interviews with Robert Cecil Martin, J. B. Rainsberger and many other TDD practitioners well known in Software craftsmanship community. Therefore I suggest to add link to http://www.wedotdd.com/ to the External links section.
About me: I am not affiliated with the suggested page. As a software developer using TDD and also leading a Munich software craftsmanship meetup I can see that the page has high relevance for the topic. It contains relevant well collected information about usage of TDD in the software development and also links to many well chosen resources recommended by the TDD related companies known and accepted in the community. I have seen that link to this page was already added to the article but it was promptly removed by editor Walter Görlitz.
Dimitry Polivaev (talk) 15:57, 26 November 2016 (UTC)
replies: text: The site feels promotional and does not appear to be a reliable source. Walter Görlitz (talk) 15:27, 4 December 2016 (UTC)

text: Promotional for whom? This site makes interviews with companies doing TDD for sharing their practices and does not promote any specific company. Do you know any more reliable site containing state-of-the information about companies practicing TDD? I don't. Dimitry Polivaev (talk) 23:19, 5 December 2016 (UTC)
replies: text:  Promotional for the site. The site does make interviews with companies doing TDD. Feel free to seek a third opinion. Walter Görlitz (talk) 06:13, 7 December 2016 (UTC)
replies: text:  Third opinion request submitted Dimitry Polivaev (talk) 20:42, 7 December 2016 (UTC)
thread_title:  Add a link to www.wedotdd.com containing interviews with companies practicing TDD and links to many high quality internet resources about TDD 

message: On the TDD cycle image after you (re)write a test the red return path is labelled as 'test succeeds" where it should be "test fails"
1.132.97.116 (talk) 18:39, 13 May 2017 (UTC)
replies: text: No. It is correct. The image, :File:TDD Global Lifecycle.png, starts with (Re)write the test. From there the state goes to, "Check if the test fails". The transition here is that if the test passes (it is labelled "succeeds") then there's a problem with the test and you need to "rewrite the test." If it fails, which is expected, you write just enough code until the test passes, and you leave that phase. In other words, if you have a test and it passes, but you have no code that is making that happen, there's a problem with the test itself or the assumption underlying the test. Walter Görlitz (talk) 20:06, 13 May 2017 (UTC)
thread_title:  Image has two labels back to front. 

message: Reading through this, it reads like advertising and a great many claims are either untestable or, where they might be testable, do not contain references or citations. An example is Receiving the expected test results at each stage reinforces the developer's mental model of the code, boosts confidence and increases productivity which is at core advertising, an untestable claim, and lacks references or citations which can support it.
Being Wikipedia, the article qualifies for instant deletion. It certainly isn't encyclopedic, it really does look like snake oil advertising for an untestable concept -- and for books written to sell the nonsense to people who are incapable of discerning snake oil.
I've been writing commercial software since 1978, I was on DARPANet before we literally voted to open the network up to public and commercial access, and over the decades I've seen supposed better way of doing things in software and hardware development come and go, and TDD looks to me to be one of the least plausible concepts, ranking up there with "Agile" and other concepts that have never achieved proven benefits, merely hype and wishful thinking. SoftwareThing (talk) 21:54, 21 January 2020 (UTC)
replies: text: That amount of negativity may give you cancer. ... Using your experience as justification to nay say holds little weight with me. I'm more impressed with action than words or credentials or age ... What about TDD does not work? Have you tried TDD? Have you tried Agile? Don't knock till you try it. ... I do think that WP should not describe benefits without saying that they are arguable; cited or possible benefits; benefits as described by proponents. Stevebroshar (talk) 20:57, 15 April 2024 (UTC)
thread_title:  Endless series of untestable claims not supported by citations 

message: Doing Ye Ole Google around the network, I can find endless examples of people religiously advocating TDD repeating all of the untestable claims made in the extant article, and that's another sign of snake oil. Selling a concept and the books which try to make a case for the supposed benefits of same with zero statistical or clinical real-word positive science-based results being offered  is classic snake oil. SoftwareThing (talk) 21:58, 21 January 2020 (UTC)
replies: text: Have you ever tried it? It works IMO. ... It's easy to nay say. But, your negativity does not bother me. I use TDD and my clients benefit. ... and good luck finding a scientific study on its value ... or similar for any software development technique. ... Honestly, it's surprising that there is no study of such things; no software development sociology. Stevebroshar (talk) 20:50, 15 April 2024 (UTC)
thread_title:  Oh, and religious dogma advocates