- TDD considered harmful - 2 Updates
- Unit testing (Re: Putting project code in many different files) - 18 Updates
- Jerry Stuckle - 5 Updates
| Dombo <dombo@disposable.invalid>: Feb 07 08:20PM +0100 Op 02-Feb-16 om 18:23 schreef Jerry Stuckle: > is true with many IC's. > Some, like microprocessors, cost more and have a higher failure rate, so > each one is tested. But not every transistor in that microprocessor. If one really needs to test every component (or make private methods public) to determine if a 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. From TDD perspective it is undesirable to have tests have intimate 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. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 07 08:26PM On Sun, 2016-02-07, 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. I agree, but wouldn't use the word "exhaustive" -- it sounds too much like "test the code with all possible inputs", which is of course almost always impossible. > 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. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 06 08:38PM -0500 On 2/6/2016 4:22 PM, Ian Collins wrote: > frameworks. If the tests pass, the make succeeds. If the fail, the > make files. > Read up on them and you might learn something. I have. And there is not a single on which will write the tests for you - or allow you to use a make file to properly test the unit. Some people think proper testing is just ensuring the correct results are returned for the correct input. That's part of it, for sure. But what is more important - and much harder to test for - is the improper input is rejected. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 06 08:39PM -0500 On 2/6/2016 5:31 PM, Wouter van Ooijen wrote: > Breaking in on this: is there a convenient way to make a test that > should fail compilation? > Wouter van Ooiejn There' shouldn't be one that fails compilation (although I guess it's possible). Testing should be directed at the processing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Feb 07 03:35PM +1300 Jerry Stuckle wrote: >> make files. >> Read up on them and you might learn something. > I have. And there is not a single on which will write the tests for you Did anyone say that they do? > - or allow you to use a make file to properly test the unit. Yes, they do. That is why people use them... > are returned for the correct input. That's part of it, for sure. But > what is more important - and much harder to test for - is the improper > input is rejected. Testing improper input is rejected is as important and usually easier to test. Proving something works with valid is often harder than proving it rejects improper input. Consider a common library function such as strtol(), it is easy to prove it rejects an invalid base, or a null input but much harder to test conversion of all of the valid input data. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 06 09:57PM -0500 On 2/6/2016 9:35 PM, Ian Collins wrote: >> I have. And there is not a single on which will write the tests for you > Did anyone say that they do? You didn't indicate there was anything to do except run the tests in a make file. > it rejects improper input. Consider a common library function such as > strtol(), it is easy to prove it rejects an invalid base, or a null > input but much harder to test conversion of all of the valid input data. Yes and no. There are generally many more invalid inputs than there are valid. strtol() is easy to test because it's a simple function. Classes and their method are seldom that easy. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Feb 07 04:12PM +1300 Jerry Stuckle wrote: >> Did anyone say that they do? > You didn't indicate there was anything to do except run the tests in a > make file. Quite, I never said a test framework writes test for me. Most provide or generate the boilerplate to run the tests however. >> input but much harder to test conversion of all of the valid input data. > Yes and no. There are generally many more invalid inputs than there are > valid. That really depends on the function. An example from the standard library would be useful. > strtol() is easy to test because it's a simple function. Classes and > their method are seldom that easy. strtol() is quite a complex function test. I have a version for an old project that has a test case split of about 60/40 for valid and invalid cases. -- Ian Collins |
| Wouter van Ooijen <wouter@voti.nl>: Feb 07 10:23AM +0100 Op 06-Feb-16 om 11:46 PM schreef Ian Collins: >> should fail compilation? > I can think of two off hand, calling a function that hasn't been written > yet and a static assert. 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. Wouter |
| Wouter van Ooijen <wouter@voti.nl>: Feb 07 10:24AM +0100 Op 07-Feb-16 om 2:39 AM schreef Jerry Stuckle: >> Wouter van Ooiejn > There' shouldn't be one that fails compilation (although I guess it's > possible). Testing should be directed at the processing. I mostly write libraries, and IMO they way they react when called with the wrong paramateres is part if their behaviour, which must be tested. It is compile-time (non run-time) behaviour, but that is still behaviour. Wouter |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 07 11:58AM +0200 On 7.02.2016 11:23, 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. And what's the problem? The only thing is that this cannot be probably done with a unit test framework meant for testing C++ code, but with some other unit test framework, or one may create a simple framework by hand: Put the code examples which are excepted to fail into .cpp files in some directory. Put the excerpts from expected error diagnostics in aux files with the same names and different extensions. During 'make test', loop over the files; for each file: Run compiler on the cpp file and capture the stderr output. Ensure that compiler exit code indicates an error. Loop over lines in the aux file and grep them in the stderr output. If the compile succeeds or any of the expected excerpts is not found, fail the make. This is a 10-line shell script which can even be inlined in the make file. |
| Wouter van Ooijen <wouter@voti.nl>: Feb 07 01:42PM +0100 Op 07-Feb-16 om 10:58 AM schreef Paavo Helde: > If the compile succeeds or any of the expected excerpts is not found, > fail the make. > This is a 10-line shell script which can even be inlined in the make file. True, in roughly the same way that a test harness is just an bunch of if statements. And I run (mostly) on windows, and I prefer not to rely on a (particular) shell and its syntax. 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? (Yes, I realise that I can easily make a program that runs a subprocess and retruns it 'inverted' return code. I just wonder if there is a more direct way, or how other people do this.) Wouter |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 07 03:20PM +0200 On 7.02.2016 14:42, Wouter van Ooijen wrote: > statements. > And I run (mostly) on windows, and I prefer not to rely on a > (particular) shell and its syntax. I am sure there are some cross-platform ways to do the same. CMake? > 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? The first google hit hints the following solution: test: /my/failing/app ; /usr/bin/test "$$?" -eq 1 # <-- make does not stop here /bin/echo "Test passed: app failed with exit code 1 as expected." |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 07 10:13AM -0500 On 2/7/2016 4:23 AM, Wouter van Ooijen wrote: > that should result in a compilation failure. This mostly arrises with > template stuff. > Wouter It's always possible to create compilation failures :) But as a serious answer to your question. Yes, it is possible to create compilation failures in template code. The question here would be, though, is the template code at fault, or is the code being misused? And for things like template code, I would consider a compiler failure if the code were being misused to be a successful test. Just another case where just a make file may not be sufficient for testing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 07 10:14AM -0500 On 2/7/2016 4:24 AM, Wouter van Ooijen wrote: > the wrong paramateres is part if their behaviour, which must be tested. > It is compile-time (non run-time) behaviour, but that is still behaviour. > Wouter In that respect, you and I are in complete agreement. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 07 10:28AM -0500 On 2/6/2016 10:12 PM, Ian Collins wrote: >> make file. > Quite, I never said a test framework writes test for me. Most provide > or generate the boilerplate to run the tests however. And their "boilerplate" is pretty much the same in all cases. You can get similar results by writing an empty main(). >> valid. > That really depends on the function. An example from the standard > library would be useful. You already mentioned it - strtol(). > strtol() is quite a complex function test. I have a version for an old > project that has a test case split of about 60/40 for valid and invalid > cases. Not really. You have a limited number of bases available, and within each base is a defined set of digits. You only need to ensure that the appropriate digits are accepted and correctly converted for the base being used. But you have a lot more invalid conditions - bad base, incorrect characters for the base being used, out of range values - the list goes on. A test suite for strtol() would involve a large number of tests, but each test is independent of the others. I would not consider it to be complex. As opposed to a class, where the success or failure of a test can easily change depending on the state of the object being tested. That is much more complex. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Wouter van Ooijen <wouter@voti.nl>: Feb 07 05:00PM +0100 Op 07-Feb-16 om 2:20 PM schreef Paavo Helde: > /my/failing/app ; /usr/bin/test "$$?" -eq 1 # <-- make does not > 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? Wouter |
| Wouter van Ooijen <wouter@voti.nl>: Feb 07 05:01PM +0100 Op 07-Feb-16 om 4:13 PM schreef Jerry Stuckle: > And for things like template code, I would consider a compiler failure > if the code were being misused to be a successful test. > Just another case where just a make file may not be sufficient for testing. OK, but how would you test (a large amount of) such features (maybe call them non-features)? Wouter |
| David Brown <david.brown@hesbynett.no>: Feb 07 05:02PM +0100 On 07/02/16 14:20, Paavo Helde wrote: >> And I run (mostly) on windows, and I prefer not to rely on a >> (particular) shell and its syntax. > I am sure there are some cross-platform ways to do the same. CMake? Another alternative is a convenient programming language for handling such things. Python is probably the most popular choice - it's cross platform, it's easy to handle things like starting processes and capturing their outputs, and it's easy to do text manipulation and comparisons. Shell scripts are fine for the simple stuff, and make is marvellous at controlling the build process, but once things get more advanced you'll be glad you picked python over eye-watering grep, awk and sed recipes. |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 07 02:27PM -0500 On 2/7/2016 11:01 AM, Wouter van Ooijen wrote: > OK, but how would you test (a large amount of) such features (maybe call > them non-features)? > Wouter Full test suites will run test cases and monitor the process. They use a hierarchical process; one of the first steps may be compiling the test code with the unit being tested; it will look for compile failures, log the failure and continue. If the compile works, the test suite will continue on with dependent tests. When a test succeeds, the suite will process dependent tests. If the test fails, processing will continue with the next independent test. It's all a matter of having a robust test suite and writing the right scripts to handle the tests. It can be time consuming, yes. But any test group that's been around for a while will have tests already developed, and often many of these tests can be modified to meet the requirements of the new tests. It's also a reason why test groups do the testing, not developers. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Wouter van Ooijen <wouter@voti.nl>: Feb 07 08:45PM +0100 Op 07-Feb-16 om 8:27 PM schreef Jerry Stuckle: > developed, and often many of these tests can be modified to meet the > requirements of the new tests. > It's also a reason why test groups do the testing, not developers. That's a nice piece of general text on testing, but it has nothing to do 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? Of course I can write Python (or other) scripts to do this, but just as 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? Wouter van Ooijen |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 06 08:36PM -0500 On 2/6/2016 5:24 PM, Öö Tiib wrote: >>> Watch your language, mr "Jerry I've got a big penis Stuckle". >> The truth hurts, doesn't it? > http://scienceblogs.com/tetrapodzoology/2008/02/22/he-loved-pigs-too-much/ You did? That's too bad... -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 07 05:08AM +0100 On 2/7/2016 2:36 AM, Jerry Stuckle wrote: >>> The truth hurts, doesn't it? >> http://scienceblogs.com/tetrapodzoology/2008/02/22/he-loved-pigs-too-much/ > You did? That's too bad... Jerry, the only sensible thing to do when someone starts a thread with your name in the subject line, is to stay out of it. It's an old flamebait/flaming device that attracts search engines and, hence, potential employer and friends, who will not only see your name associated with all kinds of unmentionable things, but will see YOU actively participating in a forum and thread where such things are bandied about. It's often done unthinkingly just for fun, and I believe that's the case here, but still it works like it's always worked. Remember that humans are first and foremost associative animals, not rational thinking beings. E.g. right now Mr Trump's rhetoric attracts a huge following. Nobody (or very few) who gets a google hit on this thread is going to think about the why of it or how you were lured into it, but they're likely to be influenced by the associations. Cheers & hth., - Alf (old Usenet denizen) |
| Robbie Hatley <see.my.sig@for.my.address>: Feb 07 02:45AM -0800 On 2/5/2016 11:37 AM, Mr Flibble wrote: >> Wrong again - and even more proof that I was right in my educated guess. > Get a proper hobby mate. > /Flibble Oh, great, just what I've always been dying to see: an episode of The Stuckle & Flibble Show. :-/ This stuff would barely be more off-topic if it was about growing begonias. -- Grouchy, Robbie Hatley Midway City, CA, USA perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"' http://www.well.com/user/lonewolf/ https://www.facebook.com/robbie.hatley |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 07 10:05AM -0500 On 2/6/2016 11:08 PM, Alf P. Steinbach wrote: > it, but they're likely to be influenced by the associations. > Cheers & hth., > - Alf (old Usenet denizen) Alf, you're right to a certain extent. I just wanted to show him how stoopid he really is. But I've already noticed he's good at that from so many of his other posts. As to being "influenced by the association" - I've gotten to the age that people like him don't bother me. And my customers are not stupid; they can easily see what's going on. But thanks for the advice. It is good. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| woodbrian77@gmail.com: Feb 07 09:09AM -0800 On Saturday, February 6, 2016 at 10:09:13 PM UTC-6, Alf P. Steinbach wrote: > Remember that humans are first and foremost associative animals, not > rational thinking beings. E.g. right now Mr Trump's rhetoric attracts a > huge following. Nobody (or very few) who gets a google hit on this https://duckduckgo.com I've been using Duckduckgo for years now and am happy with them. They don't track you the way Google and some other search engines do. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| 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