- TDD considered harmful - 4 Updates
- Unit testing (Re: Putting project code in many different files) - 5 Updates
- Jerry Stuckle - 3 Updates
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 07 04:35PM -0500 On 2/7/2016 2:20 PM, Dombo wrote: > subsystem is working correctly there is something fundamentally wrong > with the design. If exhaustive tests proof that a subsystem functions > correctly at interface level there is no need to dig any deeper. That is true. Only the function of the microprocessor is tested. And I agree - if the interface works as designed, there is nothing else to test. > knowledge about the implementation of a subsystem. Such tests are > brittle (they may fail even when the subsystem functions correctly) and > are useless for refactoring. Very true. The implementation can change at any time. And it's not necessarily unusual for that to occur. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 07 02:07PM -0800 On Tuesday, 2 February 2016 17:23:50 UTC, Jerry Stuckle wrote: [...] > No, component manufacturers don't test every individual component that > comes off the line. Again, you don't understand. It's not every individual component that is tested, it's the DESIGN of a component that is tested. How dense must you be not to understand this simple concept? If you want to design a specific component, you have to test that it does what it's supposed to do. Then, the line production is a totally different problem. Normally, we test a class, not each single instance of that class. > That isn't what I asked. You create expressions. Do you test every > expression that you write, to ensure it works properly? LOL :) What does that mean? The problem is that you keep talking about something you don't know. Stop being stupid and go study what TDD is! Your question makes no sense. I don't test the expressions, I test the code that is founded on those expressions I use, and yes, if there are any complex expressions, I test that the expressions return the correct values. |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 07 02:10PM -0800 On Sunday, 7 February 2016 19:19:57 UTC, Dombo wrote: [...] > test every component (or make private methods public) to determine if a > subsystem is working correctly there is something fundamentally wrong > with the design. TDD *IS NOT* about making private methods public. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 07 11:19PM On 07/02/2016 22:07, Zaphod Beeblebrox wrote: >> No, component manufacturers don't test every individual component that >> comes off the line. > Again, you don't understand. It's not every individual component that is tested, it's the DESIGN of a component that is tested. How dense must you be not to understand this simple concept? If you want to design a specific component, you have to test that it does what it's supposed to do. Then, the line production is a totally different problem. Normally, we test a class, not each single instance of that class. Nonsense. The problem here mate is that you cannot recognize a bad analogy. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Feb 08 09:59AM +1300 Wouter van Ooijen wrote: > I didn't express myself clear enough. I want a way to *test* the things > that should result in a compilation failure. This mostly arrises with > template stuff. Ah, I see. That is not something I have had to test, for application type code failing compiles are a step along they way rather than an actual test case. I don't know of any existing tools specifically designed for testing compile fails. I would have a good look at "expect" (see https://en.wikipedia.org/wiki/Expect). Expect is a great tool for running a command and checking for the expected result. Unless they are very generic, wouldn't go as far as looking for specific error messages. These tend to change between compiler and library versions or patches which would lead to very fragile tests. -- Ian Collins |
| "Öö Tiib" <ootiib@hot.ee>: Feb 07 01:13PM -0800 On Sunday, 7 February 2016 21:46:30 UTC+2, Wouter van Ooijen wrote: > with my specific question. I want to test that certain things *do not > compile*. Normal testharnasses are no use for this, so what would you > people out there use in such a case? It seems rather simple to test that compiler (commonly a command line program) did fail to compile something like expected. I am not sure what is the issue there. > there are gazillions of test harnassesout there, there might be someone > who has consyructed something for this kind of tests. Or am I the only > one why thingks that such things are worth testing too? You are not the only one. More and more C++ runs compile-time so such need likely increases over time. It seems like one or two lines of some makefile that are usually also needed for other tests. It is slightly trickier to automatic-test that program does really hang like expected or that platform running it does really reboot like expected or reach blue screen of death like expected or segfault and core dump like expected. Those are rarely the desired features but when these are then there sure is a way to automatize those checks as well. |
| Ian Collins <ian-news@hotmail.com>: Feb 08 10:35AM +1300 Wouter van Ooijen wrote: > By default, a makescript stops when one of the steps retruns an error. > Is there a way to enforce the opposite: the make file must stop if the > build step does *not* retrun an error? If you are using visual studio, you can place the script (be it Python or Expect or similar) that tests for compilation fails as a pre-build step rather than a part of the build. The visual studio command interpreter is very restricted, so the best option is to make it run a script. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 07 04:38PM -0500 On 2/7/2016 2:45 PM, Wouter van Ooijen wrote: > with my specific question. I want to test that certain things *do not > compile*. Normal testharnasses are no use for this, so what would you > people out there use in such a case? A full test suite will have the option to compile the code (in fact, most full test suites will compile the code first). They will check the output. If the compile fails, the test suite will detect it. > who has consyructed something for this kind of tests. Or am I the only > one why thingks that such things are worth testing too? > Wouter van Ooijen There are, and they are used by large companies. But they're also expensive (up to tens of thousands of dollars for enterprise editions). You won't find them for free. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 08 12:36AM +0200 On 7.02.2016 18:00, Wouter van Ooijen wrote: >> stop here >> /bin/echo "Test passed: app failed with exit code 1 as expected." > OK, seems like what I want, but how do I run that on windows? By installing cygwin, msys or any other unix framework which actually makes the windows box usable? Or by using a cross-platform scripting tool like Python, as suggested by others. Probably can be done in nmake as well if you are inclined to masochism. |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 07 01:57PM -0800 On Saturday, 6 February 2016 17:18:50 UTC, Prroffessorr Fir Kenobi wrote: [...] > wath yours moron LOL :) |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 07 01:58PM -0800 On Saturday, 6 February 2016 21:12:35 UTC, Jerry Stuckle wrote: [...] > The truth hurts, doesn't it? Which truth? That you've got a big penis? Doesn't seem so, judging from your posts. |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 07 02:02PM -0800 On Sunday, 7 February 2016 15:05:50 UTC, Jerry Stuckle wrote: [...] > But I've already noticed he's good at that from > so many of his other posts. The same can be said of you, Mr Jerry "Long Penis" Stuckle. Your alleged competence or intelligence certainly does not shine through your posts. > As to being "influenced by the association" - I've gotten to the age > that people like him don't bother me. Oh, we can all see that! LMAO :) |
| 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