- High horse - 10 Updates
- "Why does most C/C++ developer prefers char *c instead of char* c? Pin" - 4 Updates
- Here is my new website - 2 Updates
| Daniel <danielaparker@gmail.com>: Jun 03 06:26AM -0700 On Friday, June 1, 2018 at 11:00:51 PM UTC-4, Ian Collins wrote: > On 02/06/18 14:17, Mr Flibble wrote: > > I see Ian Collins is on his TDD high horse again. Fecking clueless. > Feel free to write code that you don't know works. Are you suggesting that TDD is the one and only way to write code that you know "works"? Works in what sense? Are you one of those people that talk about "100 percent" test coverage? Do you write tests for all your accessors, the way Robert Martin and Kent Beck do in their books? Do you think that is the best use of your time for keeping your software free of defects? A few points. One, for a non-trivial specification, it would presumably take an arbitrarily large number of tests, in some cases an infinite number, to cover off all outcomes. Since nobody has that much time, we sample, sometimes randomly, sometimes deterministically, e.g. edge cases. It's nonsensical to talk about "100" percent coverage unless you're talking about software verified through mathematical proof, and if you're talking about that, you're not talking about C++. Two, there is a significant amount of validation that cannot be approached through unit tests, I'm thinking particularly of simulation, where we need to run code for hours and calculate the statistical properties of outcomes. Best regards, Daniel |
| Daniel <danielaparker@gmail.com>: Jun 03 06:49AM -0700 On Saturday, June 2, 2018 at 4:22:41 PM UTC-4, Ian Collins wrote: > True. > https://www.thinksys.com/development/tdd-myths-misconceptions/ > Point 3. In what way does point 3 refute Mr Flibble's point? The books about TDD by authors such as Kent Beck and Robert Martin are replete with chapters where the developer starts by writing some test for something, e.g. getCustomer, attempts to compile, and discovers that compile fails! They then add some code or do some refactoring, until the test passes. Best regards, Daniel |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 03 03:43PM On Sun, 2018-06-03, Daniel wrote: >> Feel free to write code that you don't know works. > Are you suggesting that TDD is the one and only way to write code > that you know "works"? Are there /any/ ways? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 03 03:50PM On Sun, 2018-06-03, Daniel wrote: >> https://www.thinksys.com/development/tdd-myths-misconceptions/ >> Point 3. > In what way does point 3 refute Mr Flibble's point? Read it again, and work your way through the layers of negation. Flibble, Ian and the article agree that TDD isn't a software design method. > for something, e.g. getCustomer, attempts to compile, and discovers that > compile fails! They then add some code or do some refactoring, until the > test passes. That's certainly the impression I got too, from reading Beck's book once. His argument seemed weak to me. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| woodbrian77@gmail.com: Jun 03 12:15PM -0700 On Sunday, June 3, 2018 at 10:43:49 AM UTC-5, Jorgen Grahn wrote: > > Are you suggesting that TDD is the one and only way to write code > > that you know "works"? > Are there /any/ ways? "We make men without chests and expect from them virtue and enterprise. We laugh at honor and are shocked to find traitors in our midst." C.S. Lewis My approach is seeking divine guidance and help (Providence). This worked for the Pilgrims at least somewhat. Brian Ebenezer Enterprises http://webEbenezer.net |
| Daniel <danielaparker@gmail.com>: Jun 03 01:26PM -0700 > enterprise. We laugh at honor and are shocked to find traitors > in our midst." C.S. Lewis > My approach is seeking divine guidance and help (Providence). Could be working. I notice that nobody has reported an issue to Ebenezer- group/onwards https://github.com/Ebenezer-group/onwards/issues Unless there's another explanation ... Daniel |
| Ian Collins <ian-news@hotmail.com>: Jun 04 08:44AM +1200 On 04/06/18 01:26, Daniel wrote: >> Feel free to write code that you don't know works. > Are you suggesting that TDD is the one and only way to write code > that you know "works"? No. > Works in what sense? Works as in does what the detailed design (the tests) says it is supposed to do. > Are you one of those > people that talk about "100 percent" test coverage? No, in software, there is always the unexpected. But I do strive to minimise the unexpected through test coverage. > Do you write > tests for all your accessors, the way Robert Martin and Kent Beck do > in their books? Trivial accessors, no and neither to they. > Do you think that is the best use of your time for > keeping your software free of defects? Yes because it helps me write code faster and better. Maybe not initially, but the time saved in chasing down bugs, retesting after changes or stepping through code in a debugger pays off pretty quickly. Tests are an investment in the future of the code. > cases. It's nonsensical to talk about "100" percent coverage unless > you're talking about software verified through mathematical proof, > and if you're talking about that, you're not talking about C++. I don't think anyone claims otherwise. See the last point in the link I posted. > approached through unit tests, I'm thinking particularly of > simulation, where we need to run code for hours and calculate the > statistical properties of outcomes. That's correct, there should always be multiple levels of testing, again I don't think anyone claims otherwise. -- Ian. |
| Daniel <danielaparker@gmail.com>: Jun 03 02:41PM -0700 On Sunday, June 3, 2018 at 4:47:09 PM UTC-4, Ian Collins wrote: > > Works in what sense? > Works as in does what the detailed design (the tests) says it is > supposed to do. Except the tests aren't the detailed design, never were. This is simply a conceit of TDD. Much of my open source contributions are about implementing Internet Engineering Task Force (IETF) recommendations, and I don't think that I could claim much conformance if I limited myself to available test suites. Tests are better understood as sampling the specification. > > tests for all your accessors, the way Robert Martin and Kent Beck do > > in their books? > Trivial accessors, no and neither to they. Martin does, in his book Extreme Programming in Practice (2001) > > you're talking about software verified through mathematical proof, > > and if you're talking about that, you're not talking about C++. > I don't think anyone claims otherwise. You can't have it both ways, that tests _are_ the specification, as TDD'ers claim, and that tests _sample_ the specification, as everybody else would have it. Best regards, Daniel |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jun 03 10:23PM > enterprise. We laugh at honor and are shocked to find traitors > in our midst." C.S. Lewis > My approach is seeking divine guidance and help (Providence). Intuition? > This worked for the Pilgrims at least somewhat. Intuition is not always right... -- press any key to continue or any other to quit... |
| Ian Collins <ian-news@hotmail.com>: Jun 04 10:25AM +1200 On 04/06/18 09:41, Daniel wrote: > Internet Engineering Task Force (IETF) recommendations, and I don't think > that I could claim much conformance if I limited myself to available test > suites. Tests are better understood as sampling the specification. How can tests sample something that doesn't exist? Most products I have worked on (baring OTT DoD stuff in the 80s and safety critical) didn't have what heavyweight processes would recognise as a detailed design specification. Most stop at the layer above or user stories which are probably the most common "requirement" in non-safety critical projects. If the "specification" is a user story, the tests break that down into a series of steps needed to complete the story. The tests bridge the gap between what the user asks for and the code. The entity that bridges the gap between what the user asks for and the code is usually called a specification.. Would you consider writing a detailed design to bridge the gap between what the user asks for and the code as sampling the specification? If where is the conceit? If no, how does a requirement written in prose differ from one written in code? I have written software to generate test cases form the clauses in formal detailed design on medical products (IEC 62304 class B&C) and these ended up being a subset of the actual test cases for the code. So the tests were more detailed than the formal detailed design; at least until they were fed back into the design. >>> in their books? >> Trivial accessors, no and neither to they. > Martin does, in his book Extreme Programming in Practice (2001) That isn't what Kent Beck described. > You can't have it both ways, that tests _are_ the specification, as TDD'ers > claim, and that tests _sample_ the specification, as everybody else would > have it. I was responding to "It's nonsensical to talk about "100" percent coverage". -- Ian. |
| Ian Collins <ian-news@hotmail.com>: Jun 03 08:32AM +1200 On 03/06/18 08:26, Bart wrote: > forget to name it and it happens to shadow a more global variable with > the same name? > Let me guess: unit tests will pick that up. So why ask? -- Ian. |
| guinness.tony@gmail.com: Jun 02 04:47PM -0700 > (I don't know if it's mine that's broken. My posts look fine via googlgroups. And also (since for some reason I get notified on it) on whatever app is used on my Android phone). Is it that hard for a newsreader to ensure that too-long lines are wrapped properly for display?) > -- > bartc And yet you can't be arsed to format your lines to less than 80 characters. It's really not that hard. But, then again, you're Bart and find even the simplest tasks hard. |
| David Brown <david.brown@hesbynett.no>: Jun 03 05:27PM +0200 On 02/06/18 22:17, Ian Collins wrote: >> (for example, to give consistent interfaces to a number of functions), >> then I use "__attribute__((unused))" or cast the variable to void. > Which is all well and good in C, C++ has unnamed parameters for that case. And C++ also lets you name the parameters. Unnamed parameters make sense for purely overload purposes, including types with only a single object (like nullptr_t, nothrow_t, etc.). There would usually be no reason to use the parameter of such types. But other than that, I /want/ parameters to have names - even if I don't use them. |
| David Brown <david.brown@hesbynett.no>: Jun 03 05:30PM +0200 On 02/06/18 22:32, Ian Collins wrote: >> the same name? >> Let me guess: unit tests will pick that up. > So why ask? Maybe you'd spot the problem using compiler warnings, before even having to run the tests? |
| guinness.tony@gmail.com: Jun 02 04:36PM -0700 On Saturday, 2 June 2018 20:51:17 UTC+1, Sky89 wrote: > You are welcome. > Thank you, > Amine Moulay Ramdane. And yet you still won't stop you treating comp.programming.threads as your personal blog, nor will it stop you spamming comp.lang.c++ with your inanity. |
| Sky89 <Sky89@sky68.com>: Jun 02 07:41PM -0400 >> Thank you, >> Amine Moulay Ramdane. > And yet you still won't stop you treating comp.programming.threads as your personal blog, nor will it stop you spamming comp.lang.c++ with your inanity. Don't bother, i am posting just very few posts here on this forum of C++. Thank you, Amine Moulay Ramdane. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment