This is the
talk page for discussing improvements to the
Test-driven development article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||
|
The content of this article has been derived in whole or part from
http://www.pathfindersolns.com. Permission has been received from the copyright holder to release this material under both the
Creative Commons Attribution-ShareAlike 3.0 Unported license and the
GNU Free Documentation License. You may use either or both licenses. Evidence of this has been confirmed and stored by
VRT volunteers, under ticket number
2012112810010438. This template is used by approved volunteers dealing with the Wikimedia volunteer response team system (VRTS) after receipt of a clear statement of permission at permissions-en wikimedia.org. Do not use this template to claim permission. |
The "Limitations" section says that TDD "is currently immature". I don't understand what is meant by that.
It also lists "GUI" as one of the limitations. As someone who works on complex Swing applications for a living and even has written a whole book chapter about TDDing Swing GUIs, I guess I simply disagree. It would be nice if the original author could clarify why he thinks it is a limitation.
Thanks!
Ilja
In limitation #4, mention is made of fixing tests when refactoring invalidates them. I have run into this problem myself. I have looked for information on how to handle this situation and found nothing. This may be one of the things that make TDD immature. I would very much like to see details of how one can fix tests. -- NathanHoltBeader ( talk) 22:23, 25 August 2009 (UTC)
Some of the citations here are pretty shaky. There's a link to a developer's personal diary (Citation 21) and a link to a blog post from a single developer who is not widely known as a practices expert (Citation 22). This isn't to say there isn't some valid criticism out there, but neither of those are particularly impressive examples of the arguments against TDD. We either need some serious, wide circulation citations, or better yet some studies of effects on productivity with negative outcomes Nicklbailey ( talk) 21:43, 11 April 2017 (UTC)
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)
The link in the note 3 is not good. /info/en/?search=Test-driven_development#cite_note-Cworld92-3 — Preceding unsigned comment added by Apieum ( talk • contribs) 11:28, 30 November 2019 (UTC)
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.
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)
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)
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)
Test driven development is a great idea. But some of the claims in the Benefits section are unsupported. I think at the least they need to be cited, or downgrade the claims to be opinions (and reference those who hold these opinions). For example, the claim that even though more code is written, that a project can be completed more quickly. Has anyone documented an experiment with two identical teams one using TDD and the other not?
Similarly, the claim that TDD programmers hardy ever need to use a debugger sounds ludicrous to me (how about debugging the tests?). As well as the claim that it's more productive to delete code that fails a test and rewrite it, than it is to debug and fix it??? Here's the current text from the article:
Mike Koss 21:57, 28 July 2007 (UTC)
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
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)
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)
Certainly Black Box and White Box is used in testing, but not usually in TDD, where the tests are written before the code. That said. there is always the issue of whether to test the internals of code or just the public API. Internals: more detailed checking of state. Externals: guarantee stability of public API, provides good code examples for others. SteveLoughran ( talk) 22:10, 25 May 2008 (UTC)
Ja test-Driven Development consist of many prototypes Ja —Preceding unsigned comment added by 196.21.61.112 ( talk) 07:45, 1 September 2008 (UTC)
I made this edit for the Code Visibility para, which has been reverted.. incorrectly IMHO. I'd be willing to discuss it if the person who reverted it back wishes to.. or can cite sources which support that section. I already linked to a mailing list post by Dave Astels, who wrote the other TDD book Gishu Pillai ( talk) 16:36, 6 December 2008 (UTC)
If you think something is worth to be tested and still it should be private, this is a code smell. You should consider to move this code to a new class where it is legitimately public and create a private instance of this class at the original place. — Preceding unsigned comment added by 93.192.8.123 ( talk) 07:48, 30 May 2011 (UTC)
Agreed with previous comment. From practical application in industry, a unit test within a TDD project does not test the hidden data or functionality of a unit, only the public interface. By definition the private or hidden members are part of the implementation, not the API. Qbradq ( talk) 15:51, 9 August 2013 (UTC)
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) oluwaseun —Preceding unsigned comment added by 81.199.145.162 ( talk) 10:20, 9 October 2009 (UTC)
Likewise, this quotation in the Development style section:
In Test-Driven Development by Example Kent Beck also suggests the principle "Fake it till you make it".
What does that mean in the context of TDD? —Preceding unsigned comment added by 142.244.167.122 ( talk) 00:18, 8 April 2011 (UTC)
Dvanatta ( talk) 04:54, 9 December 2011 (UTC) To explain the concept: the key is that the client of the code is written before the code itself is written. Said in another way, before you write code, you write an example of how that code should work. Hence, when writing client code, if you find it really tedious to use the code you plan to write, you may discover changes to the interfaces and design that make the code more natural and easier to use. These are changes you learn about only after writing examples of client code. Thus, it is the examples of how you would use the code that can determine and even drive the exact design and interface of that code.
"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)
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)
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)
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)"
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)
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)
This item:
Isn't an argument against test-driven development, but rather an argument against poor implementations of test-driven development. That testing causes some overhead is a given, but it's a necessary cost to get the benefits. Tanath ( talk) 20:42, 7 February 2013 (UTC)
The whole section (Shortcomings) seems to be written from a flawed perspective. It assumes that unit tests are intended to find defects and detect regressions. It describes the shortcomings of approaching TDD from this flawed perspective, not of the methodology itself. I would like to re-write the section as listing this common misconception as a potential pitfall, including the complications already listed. Qbradq ( talk) 14:58, 9 August 2013 (UTC)
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)
This edit is a bit disconcerting when it states "TDD is not about unit tests so the paragraph is worthless". The sentence that was removed does not state that at all only that there is a reliance on unit tests, which is true. perhaps we should discuss this removal of content. Walter Görlitz ( talk) 22:41, 21 March 2014 (UTC)
This article appears to be in pretty poor shape at the moment.
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)
@ Walter Görlitz: 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
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)
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)
Response to third opinion request: |
I don't believe this link adds anything to the quality of the article, and therefore should be avoided. Generally, if the addition of a link improves the article it can be added. If it instead improves the reputation of the external website, or attempts to drive traffic to that site, it should not be added. See WP:REFSPAM for more information on external links. Bradv 21:47, 7 December 2016 (UTC) |
I have semi protected the article for a week. There was an edit war over this edit. I'd like to point out that, where there is disagreement, the onus is on those who want to include content to get consensus to do that. If editors want to include the link, I suggest they describe why here, on the talk page, rather than edit warring. Yaris678 ( talk) 20:27, 26 December 2016 (UTC)
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) Simon
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)
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)
If I have read the article correctly, then nothing is being said about the following problem and the best-practice to handle it:
If you know about a bug or a limitation in your software and the client wants that you should not fix it (because it's just a corner case and/or too expensive to fix or you have no resources or it's not included in current release or whatever), then what do you do about this? There are three possibilities:
What is best practice for this problem? This should be added to the article (with references of course), because this is fundamental to someone new to this topic. -- 165.222.180.133 ( talk) 16:57, 31 January 2020 (UTC)
This is the
talk page for discussing improvements to the
Test-driven development article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||
|
The content of this article has been derived in whole or part from
http://www.pathfindersolns.com. Permission has been received from the copyright holder to release this material under both the
Creative Commons Attribution-ShareAlike 3.0 Unported license and the
GNU Free Documentation License. You may use either or both licenses. Evidence of this has been confirmed and stored by
VRT volunteers, under ticket number
2012112810010438. This template is used by approved volunteers dealing with the Wikimedia volunteer response team system (VRTS) after receipt of a clear statement of permission at permissions-en wikimedia.org. Do not use this template to claim permission. |
The "Limitations" section says that TDD "is currently immature". I don't understand what is meant by that.
It also lists "GUI" as one of the limitations. As someone who works on complex Swing applications for a living and even has written a whole book chapter about TDDing Swing GUIs, I guess I simply disagree. It would be nice if the original author could clarify why he thinks it is a limitation.
Thanks!
Ilja
In limitation #4, mention is made of fixing tests when refactoring invalidates them. I have run into this problem myself. I have looked for information on how to handle this situation and found nothing. This may be one of the things that make TDD immature. I would very much like to see details of how one can fix tests. -- NathanHoltBeader ( talk) 22:23, 25 August 2009 (UTC)
Some of the citations here are pretty shaky. There's a link to a developer's personal diary (Citation 21) and a link to a blog post from a single developer who is not widely known as a practices expert (Citation 22). This isn't to say there isn't some valid criticism out there, but neither of those are particularly impressive examples of the arguments against TDD. We either need some serious, wide circulation citations, or better yet some studies of effects on productivity with negative outcomes Nicklbailey ( talk) 21:43, 11 April 2017 (UTC)
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)
The link in the note 3 is not good. /info/en/?search=Test-driven_development#cite_note-Cworld92-3 — Preceding unsigned comment added by Apieum ( talk • contribs) 11:28, 30 November 2019 (UTC)
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.
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)
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)
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)
Test driven development is a great idea. But some of the claims in the Benefits section are unsupported. I think at the least they need to be cited, or downgrade the claims to be opinions (and reference those who hold these opinions). For example, the claim that even though more code is written, that a project can be completed more quickly. Has anyone documented an experiment with two identical teams one using TDD and the other not?
Similarly, the claim that TDD programmers hardy ever need to use a debugger sounds ludicrous to me (how about debugging the tests?). As well as the claim that it's more productive to delete code that fails a test and rewrite it, than it is to debug and fix it??? Here's the current text from the article:
Mike Koss 21:57, 28 July 2007 (UTC)
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
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)
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)
Certainly Black Box and White Box is used in testing, but not usually in TDD, where the tests are written before the code. That said. there is always the issue of whether to test the internals of code or just the public API. Internals: more detailed checking of state. Externals: guarantee stability of public API, provides good code examples for others. SteveLoughran ( talk) 22:10, 25 May 2008 (UTC)
Ja test-Driven Development consist of many prototypes Ja —Preceding unsigned comment added by 196.21.61.112 ( talk) 07:45, 1 September 2008 (UTC)
I made this edit for the Code Visibility para, which has been reverted.. incorrectly IMHO. I'd be willing to discuss it if the person who reverted it back wishes to.. or can cite sources which support that section. I already linked to a mailing list post by Dave Astels, who wrote the other TDD book Gishu Pillai ( talk) 16:36, 6 December 2008 (UTC)
If you think something is worth to be tested and still it should be private, this is a code smell. You should consider to move this code to a new class where it is legitimately public and create a private instance of this class at the original place. — Preceding unsigned comment added by 93.192.8.123 ( talk) 07:48, 30 May 2011 (UTC)
Agreed with previous comment. From practical application in industry, a unit test within a TDD project does not test the hidden data or functionality of a unit, only the public interface. By definition the private or hidden members are part of the implementation, not the API. Qbradq ( talk) 15:51, 9 August 2013 (UTC)
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) oluwaseun —Preceding unsigned comment added by 81.199.145.162 ( talk) 10:20, 9 October 2009 (UTC)
Likewise, this quotation in the Development style section:
In Test-Driven Development by Example Kent Beck also suggests the principle "Fake it till you make it".
What does that mean in the context of TDD? —Preceding unsigned comment added by 142.244.167.122 ( talk) 00:18, 8 April 2011 (UTC)
Dvanatta ( talk) 04:54, 9 December 2011 (UTC) To explain the concept: the key is that the client of the code is written before the code itself is written. Said in another way, before you write code, you write an example of how that code should work. Hence, when writing client code, if you find it really tedious to use the code you plan to write, you may discover changes to the interfaces and design that make the code more natural and easier to use. These are changes you learn about only after writing examples of client code. Thus, it is the examples of how you would use the code that can determine and even drive the exact design and interface of that code.
"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)
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)
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)
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)"
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)
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)
This item:
Isn't an argument against test-driven development, but rather an argument against poor implementations of test-driven development. That testing causes some overhead is a given, but it's a necessary cost to get the benefits. Tanath ( talk) 20:42, 7 February 2013 (UTC)
The whole section (Shortcomings) seems to be written from a flawed perspective. It assumes that unit tests are intended to find defects and detect regressions. It describes the shortcomings of approaching TDD from this flawed perspective, not of the methodology itself. I would like to re-write the section as listing this common misconception as a potential pitfall, including the complications already listed. Qbradq ( talk) 14:58, 9 August 2013 (UTC)
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)
This edit is a bit disconcerting when it states "TDD is not about unit tests so the paragraph is worthless". The sentence that was removed does not state that at all only that there is a reliance on unit tests, which is true. perhaps we should discuss this removal of content. Walter Görlitz ( talk) 22:41, 21 March 2014 (UTC)
This article appears to be in pretty poor shape at the moment.
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)
@ Walter Görlitz: 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
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)
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)
Response to third opinion request: |
I don't believe this link adds anything to the quality of the article, and therefore should be avoided. Generally, if the addition of a link improves the article it can be added. If it instead improves the reputation of the external website, or attempts to drive traffic to that site, it should not be added. See WP:REFSPAM for more information on external links. Bradv 21:47, 7 December 2016 (UTC) |
I have semi protected the article for a week. There was an edit war over this edit. I'd like to point out that, where there is disagreement, the onus is on those who want to include content to get consensus to do that. If editors want to include the link, I suggest they describe why here, on the talk page, rather than edit warring. Yaris678 ( talk) 20:27, 26 December 2016 (UTC)
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) Simon
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)
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)
If I have read the article correctly, then nothing is being said about the following problem and the best-practice to handle it:
If you know about a bug or a limitation in your software and the client wants that you should not fix it (because it's just a corner case and/or too expensive to fix or you have no resources or it's not included in current release or whatever), then what do you do about this? There are three possibilities:
What is best practice for this problem? This should be added to the article (with references of course), because this is fundamental to someone new to this topic. -- 165.222.180.133 ( talk) 16:57, 31 January 2020 (UTC)