- TDD considered harmful - 6 Updates
- Unit testing (Re: Putting project code in many different files) - 17 Updates
- February meetings - 1 Update
- Let's talk about multiple inheritance and interfaces. - 1 Update
| Robert Wessel <robertwessel2@yahoo.com>: Feb 02 12:08AM -0600 On Mon, 1 Feb 2016 04:23:35 -0800 (PST), >Designing software through trial and error by fixing failing "tests" rather than by applying some intelligence and thinking about abstractions, interfaces, class hierarchies and object hierarchies is, quite frankly, both absurd and possibly even harmful and I am amazed that you cannot see this. >TDD is the totally wrong approach to software development. Design first, implement second and unit test third. Waterfall is back in fashion? Why not, I saw someone selling tie-dye kits at the mall the other day. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 01 11:40PM -0800 > >TDD is the totally wrong approach to software development. Design first, implement second and unit test third. > Waterfall is back in fashion? Why not, I saw someone selling tie-dye > kits at the mall the other day. "Agile" basically means "using two-week waterfalls". |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 02:57AM -0800 On Sunday, 31 January 2016 21:23:37 UTC, Mr Flibble wrote: [...] > You obviously don't understand class invariants. ...I do, and you are obviously a troll :) >Any language that > doesn't offer private methods doesn't offer a way to easily enforce a > class invariant Wrong. The keyword "private" can be changed to "public" at any time, by anyone, and a private method can be made publicly accessible with a snap of the fingers. The various access specifiers are not a way to "lock" a class; they define a contract. A private method tell the client programmer that they shouldn't be using that method, and the compiler enforces that check. But anyone wants to change the contract, can do that, so it's not different than just a syntactic convention. When you write a method with an underscore in Python/JavaScript, you are telling the client programmer that they are not supposed to call that method directly. It's a way to define a contract. Same thing as access specifiers. > Python and JavaScript are both toy. Yeah, and you are a troll :) |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 02:58AM -0800 On Sunday, 31 January 2016 23:29:09 UTC, Jerry Stuckle wrote: [...] > If the circuit works properly, you don't have to test each individual > electronic component. If the circuit works properly, it's just because each electronic component has been individually tested. |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 02:59AM -0800 On Sunday, 31 January 2016 21:20:19 UTC, Mr Flibble wrote: [...] > >> If you eschew private methods and instead make everything public > > That's not what TDD is. > Sure it is. No, it's not. |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 03:03AM -0800 On Monday, 1 February 2016 00:56:45 UTC, Mr Flibble wrote: [...] > TDD is anathema to best (SOLID) practices related to the > design of non-trivial software systems. Unfortunately, Uncle Bob, one of the first experts naming the SOLID principles, disagrees with you: https://skillsmatter.com/courses/418-uncle-bobs-test-driven-development-and-refactoring |
| legalize+jeeves@mail.xmission.com (Richard): Feb 02 12:23AM [Please do not mail me a copy of your followup] Jerry Stuckle <jstucklex@attglobal.net> spake the secret code >Once you have tested B and are sure it works, you can use it in other >tests. For instance, if A is derived from B or has B as a member, >before you can thoroughly test A you have to ensure B works. If B is a value type, like std::string but application domain specific, I agree. If B is not a value type, but encapsulates some policy of business logic or behavior in your application domain, I disagree. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Feb 02 12:25AM [Please do not mail me a copy of your followup] 4ndre4 <4ndre4@4ndre4.com.invalid> spake the secret code >tests. Collaborations between classes should be mocked. The tests for >class B can run independently from those for class A, even though A >inherits from B. I agree, provided that B is modeled as an abstraction of behavior or policy and you mock the abstraction. When B is a value type for something like a 3D point or 4x4 transformation matrix (examples from 3D graphics), then you just use B directly without mocking it. The same way you don't bother mocking std::string -- you just use it as a value type in your other classes. Even if you made your own string like clang's StringRef, you still wouldn't mock it. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Ian Collins <ian-news@hotmail.com>: Feb 02 01:38PM +1300 Richard wrote: > std::string -- you just use it as a value type in your other classes. > Even if you made your own string like clang's StringRef, you still > wouldn't mock it. That's a good distinction to make. I see it's one I have followed without explicitly setting out to do so. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 08:09PM -0500 On 2/1/2016 3:41 PM, Ian Collins wrote: >> Not at all. > You appear to find the concept of developers delivering tested code a > hard one to grasp. Not at all. But you seem to find the concept of testing code independent of whomever wrote the code to be a hard one to grasp. It is the general process in any science. Review of anything by an independent body is key to validation of whatever is being reviewed. But some developers think they can do a better job of reviewing code than someone independent of the development cycle. It's a main reason there are so many errors in code. >> back and see. > Indeed I did, but where did I say anything about not having "a test > group and test system(s)"? You said you wouldn't stress test code on a development system. Nothing more. Look back and see. >> You said you can't test for out of memory on a development system. Look >> back and see. > I know, but where did I say anything about there not being a test group? You said you can't test for out of memory on a development system. Nothing more. Look back and see. >> Look back and see. > I know, but how was mentioning embedded systems as an example changing > the topic? Please explain. Until you mentioned embedded systems, no one else had. But you can't see your strawman argument. >> the developers were doing the testing instead of writing the code. >> Projects that were late and over budget. > So you are an advocate for developers delivering untested code? Testing needs to be done by the test group. Developers need to be developing code. I never said the developers should *never* test code. But once a class is completed, it needs to be turned over to the test group. If there is some basic testing by the developer, fine. But not much. The developer's time is much more expensive than the tester's time. >>> device is a class other code". There, is that clear now? >> Yes, it is perfectly clear you have no idea what you're talking about. > Ah good, an insult. I'll take that as a concession. No concession. Just an observation based on your comments. >> Nope. But I don't try to mock classes, either. It just leads to more >> work and more bugs. > Ah good, avoiding the issue by changing the topic. Yup. Sorry you can't see that. >> Nope. Not at all. But you obviously don't understand the difference >> between hardware and software. > Response by insult again, good. No more of an insult than the many you've made. But I know you already. You *never* insult others. You're *always* right in *everything* you do. ROFLMAO! You wouldn't make it two weeks in any of the projects I've worked on - either as a developer or a project manager. Enough here. You've shown you can't be reasoned with. I'm done with you. You can have the last word. I know you need it. Your ego demands it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 08:14PM -0500 On 2/1/2016 4:14 PM, Paavo Helde wrote: > efforts in the future. And there are no testers involved, I'm talking > about automated test suite runs triggered either be the developer > manually or then automatically by each check-in. It is a waste of time if the problems could have been detected and corrected earlier in the process. The longer into the development you go before an error is detected, the more expensive the correction. > dirtier. This means that in addition to adding the concrete feature or > bugfix one should also look at the surrounding code and try to make it > all work more smoothly together. Not if there is a good design in the first place. I do not subscribe to the TDD/agile process for anything other than the smallest of projects. Decades of development has shown that bugs are directly related to LOC written, not total LOC. Rewriting code adds bugs in the long run; while it might remove one or two bugs, it can very well add three or four more bugs. > must be working and pass their unit tests before you can start refactoring. > Cheers > Paavo If A depends on B, you need to test B (the independent class) to ensure it runs properly before you can thoroughly test A. In the long run, refactoring code always adds more bugs than doing it right in the first place. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 08:16PM -0500 On 2/1/2016 3:59 PM, Ian Collins wrote: > You must have missed this memo when you were there: > http://collaboration.csc.ncsu.edu/laurie/Papers/agile07.pdf > Care to comment? Not to a noob, I don't. That is one person's opinion. Nothing more, nothing less. It's worth about as much as your opinion against experts. - ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 08:19PM -0500 On 2/1/2016 7:23 PM, Richard wrote: > specific, I agree. > If B is not a value type, but encapsulates some policy of business > logic or behavior in your application domain, I disagree. It doesn't matter whether B is a value type or an encapsulation of some business policy. You can't test A thoroughly until B is working correctly. And if B is an encapsulation of a business policy, it is even more important that that policy be validated as part of A's testing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Feb 02 03:03PM +1300 Jerry Stuckle wrote: >> hard one to grasp. > Not at all. But you seem to find the concept of testing code > independent of whomever wrote the code to be a hard one to grasp. Citation please. >> group and test system(s)"? > You said you wouldn't stress test code on a development system. Nothing > more. Look back and see. Good, so we agree that I didn't say anything about not having "a test group and test system(s)". >> I know, but where did I say anything about there not being a test group? > You said you can't test for out of memory on a development system. > Nothing more. Look back and see. Good, so we agree that I didn't say anything about not having "a test group and test system(s)". >> the topic? Please explain. > Until you mentioned embedded systems, no one else had. But you can't > see your strawman argument. I didn't deny I was the first to mention embedded systems. You have yet to show how mentioning them in any way changed the subject. >> Response by insult again, good. > No more of an insult than the many you've made. But I know you already. > You *never* insult others. You're *always* right in *everything* you do. So we agree on something, good... > You wouldn't make it two weeks in any of the projects I've worked on - > either as a developer or a project manager. By the sound of it, I wouldn't want to. Although I probably would enjoy doing TDD at IBM. > Enough here. You've shown you can't be reasoned with. I'm done with > you. You can have the last word. I know you need it. Your ego demands it. Stop looking in the mirror when you type...... -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 02 03:08PM +1300 Jerry Stuckle wrote: >> Care to comment? > Not to a noob, I don't. That is one person's opinion. Nothing more, > nothing less. It's worth about as much as your opinion against experts. You didn't even read the paper, did you? It's good to see you revert to type and start name calling. I guess you will be moving on to yet another group now? -- Ian Collins |
| Gareth Owen <gwowen@gmail.com>: Feb 02 07:11AM >> Enough here. You've shown you can't be reasoned with. I'm done with >> you. You can have the last word. I know you need it. Your ego demands it. > Stop looking in the mirror when you type...... Ian, its Jerry Stuckle. He has no interest in your actual opinions, only in how he'd like to portray them. Just imagine him as Donald Trump, and realise you're wasting your breath. |
| Gareth Owen <gwowen@gmail.com>: Feb 02 07:15AM > I don't need to do any research on it. I've seen it tried. Ladies and Gentlemen, Donald Trump |
| Gareth Owen <gwowen@gmail.com>: Feb 02 07:18AM > Not to a noob, I don't. That is one person's opinion. Nothing more, > nothing less. Oh, the irony. Thanks Donald, you've provided some good chuckles. |
| Ian Collins <ian-news@hotmail.com>: Feb 02 08:37PM +1300 Gareth Owen wrote: > only in how he'd like to portray them. > Just imagine him as Donald Trump, and realise you're wasting your > breath. Oh I know who I was dealing with. It was an amusing distraction form real work :) -- Ian Collins |
| Gareth Owen <gwowen@gmail.com>: Feb 02 07:51AM > Oh I know who I was dealing with. It was an amusing distraction form > real work :) Oh, well, then please continue. I've actually created a mock Jerry for you to practice with. It's not a full implementation, but it meets the specifications. class Stuckle { private: int insecurity, doubt, ignorance; virtual void knowledge(); public: // int self_awareness; // Maybe in v2.0 void argue(std::string&your_argument) { std::cout << "You're wrong\nI'm right\nI worked at IBM you know\n"; } }; |
| David Brown <david.brown@hesbynett.no>: Feb 02 10:11AM +0100 On 01/02/16 17:02, Jerry Stuckle wrote: > their code; just minimal - enough to see that it does what they > expected, anyway. Then the code goes to the test group who's > responsibility to make it fail. Developers' time is too valuable to waste on long cycles of passing code around departments and waiting for feedback, instead of just testing their code themselves. And testers' time is too valuable to waste finding bugs that the developer could spot, instead of doing system tests, integration tests, regression tests and other higher-level testing. When things are working perfectly, the test group's job is to confirm that everything works, not find the bugs or make the code fail. If the specifications are good, and the development team code correctly to those specifications, then the test group should never find anything wrong. Things are seldom that ideal in practice, but that is the aim. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 02 11:27AM +0200 On 2.02.2016 3:14, Jerry Stuckle wrote: > In the long run, refactoring code always adds more bugs than doing it > right in the first place. Agreed. What I'm trying to make clear it is not possible to get everything right in the first place, if not for any other matters then because the requirements change. So refactoring is needed, do we like it or not. Let me give you an illustrative example about what kind of things I have in mind when talking about changing requirements (this is just an illustration, based very loosely on real life events, take it as literature): Instrument people come to us and say: The new instrument will spit out multiple microscope images for different laser wavelengths. The problem however is we cannot position the things perfectly, so the channels are shifted according to each other. But do not worry, we have devised a calibration step with an artificial sample so that you could find out the actual shift in the beginning of the run and correlate against it in the software. And it must happen fast as the thing is run during the real experiment and there will be thousands of images. Can you guys do that? We say: correlating the images automatically can be done, and cropping rectangular areas out of images is a piece of cake, no problem. Are you sure there are no other corrections needed? Can we see the images? They say: yes-yes, it's just the shift, nothing else. Even if there are other deviations, they will be small and you can ignore them. And no, there are no images yet as the instrument is not built, but you need to start coding now because it would be too late otherwise. Fine, we prepare software modules for correlating the images, finding the shift and cropping out overlapping rectangles before passing them along to other analysis. Some months pass. The instrument people ask: Is the software ready? And how exactly do you correlate against different magnifications? We say: What? You have told nothing about different magnifications? They: well, they are there, we cannot align the hardware perfectly so one channel has a bit different magnification than the other. Ok, now we have to rethink our algorithm because now we have to start resampling pixels and need to decide which resampling method introduces the least artifacts in the later statistical analysis. We also have to extend the interface between modules to pass a couple of more numbers. Some months pass. Instrument people give us the first images from the instrument. We pass them through the software and the results are not so good. We turn back to instrument people: your images are slightly rotated against each other! They say: do not worry, we will tune the hardware and the rotation will go away. Some months pass. Instrument people come back to us: we cannot get rid of the rotation, you have to include this in your algorithm. And it must still run as fast as possible! OK, we add a couple of more parameters and enhance our analysis and correction routines. The results go better. However, they are not perfect. We go back to the instrument people: It looks like your images have varying non-linear distortions all over the image! They: this cannot be, this is physically impossible! (and after some more back and forth) - let us investigate! Some months pass. Instrument people come back to us: you guys were right, there are indeed non-linear distortions we cannot explain. Fix them! And so we end up with a solution which finds the full distortion shift fields over the whole image, and then resamples actual images using this field, pixelwise. Instead of a couple of integer shift parameters there is now the full distortion field (millions of floating-point parameters). The workflow must be redesigned because passing millions of parameters is different than passing a couple of them, and the correction step now takes significantly longer. And yes I agree coding the final algorithm in the first place would have been less work and less bugs than redoing it multiple times. Alas, nobody could see it up-front. Even if anybody had proposed that up-front, the project managers would never have agreed with such a space- and time-inefficient solution. |
| Ian Collins <ian-news@hotmail.com>: Feb 02 10:31PM +1300 David Brown wrote: > specifications are good, and the development team code correctly to > those specifications, then the test group should never find anything > wrong. Things are seldom that ideal in practice, but that is the aim. If the developers and the testers are doing a good job, the "bugs" will turn out to be ambiguities in the specification! -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 07:58PM -0500 > Brian > Ebenezer Enterprises - In G-d we trust. > http://webEbenezer.net Lots of BS. For instance, the Washington, DC group hasn't met in over two years, AFAIK. If someone is going to publicize user groups, they should at least make *some* effort to see that the group meets (or even exists). -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 07:56PM -0500 On 2/1/2016 4:20 PM, Vir Campestris wrote: > <http://www.spanishdict.com/translate/tonto> > (I didn't know that when I was a kid...) > Andy Tonto was an American Indian name (I forget which tribe), not Spanish. Tonto was the name of the Lone Ranger's partner. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.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