- TDD can be useful even when it doesn't achieve what you want - 1 Update
- TDD considered harmful - 14 Updates
- Brian Wood's C++ Middleware Writer Spam Advertising - 4 Updates
- send email and socket programming - 6 Updates
| Juha Nieminen <nospam@thanks.invalid>: Feb 15 09:49PM As a contrast to the recent "TDD is harmful" thread, I would like to recount something I thought of recently in regards to a situation where TDD doesn't actually achieve what you want, but can still make your code better regardless. Suppose you have a problem like this: You have made a small class that opens a file (for example an image file) and does something with it. One of the things you want to test is that the class actually ends up closing the file (at the latest when it's destroyed). How would you test this? Since you are TDD-conscious, mock objects come to you naturally. Therefore the solution seems to be clear: You have to make a mock object that behaves like a file handle. To do this, you have to change the class so that it takes a more abstract file handle than eg. a FILE* or a std::istream. Once this is done, you can easily create a test to make sure that your file-handling class ends up eventually closing the file (by creating a mock file handler object that makes this check and giving it to the class.) However, there's a problem here: How do we now test that this abstract file handle (which itself uses eg a FILE* or a std::istream) ends up closing the file (at the latest when it's destroyed)? We realize that all we have done is just transfer the problem to another class, and we have ended up in an ouroboros situation. How could we test this? Create yet *another* abstract file handle which we can mock? That wouldn't make much sense since we just did exactly that, and it didn't really help. We would just be in a vicious cycle. So TDD didn't actually help us solve the actual problem we were trying to solve. *However* TDD *did* help us, in a natural way, to make our original class better. That's because now it's more abstract and flexible. We have changed it from being hard-coded to use a standard file handle into being abstract, which makes it more flexible. (After all, it now supports other types of input for the data it needs to read. We can now make all kinds of abstract "file handle" objects that feed it data from whatever other resource that might not be a file.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Gert-Jan de Vos <gert-jan.de.vos@onsneteindhoven.nl>: Feb 15 05:42AM -0800 You might be interested to read these articles on TDD by a well respected author. He elaborates on several downsides of TDD here: http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf http://www.rbcs-us.com/documents/Segue.pdf |
| legalize+jeeves@mail.xmission.com (Richard): Feb 15 05:12PM [Please do not mail me a copy of your followup] Gert-Jan de Vos <gert-jan.de.vos@onsneteindhoven.nl> spake the secret code >respected author. He elaborates on several downsides of TDD here: >http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf >http://www.rbcs-us.com/documents/Segue.pdf James Coplien and Uncle Bob discussing TDD: <https://www.youtube.com/watch?v=KtHQGs3zFAM> -- "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> |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 15 08:11PM +0200 On 15.02.2016 15:42, Gert-Jan de Vos wrote: > You might be interested to read these articles on TDD by a well respected author. He elaborates on several downsides of TDD here: > http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf > http://www.rbcs-us.com/documents/Segue.pdf Tried to read these links. To me it seems he is putting up several straw men and then attacking them vehemently. One of these is that he seems to be using some non-productive definition of "unit test" and then goes to great lengths to show that creating and using such tests is, err, non-productive. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 15 10:55AM -0800 On Monday, 15 February 2016 19:13:13 UTC+2, Richard wrote: > >http://www.rbcs-us.com/documents/Segue.pdf > James Coplien and Uncle Bob discussing TDD: > <https://www.youtube.com/watch?v=KtHQGs3zFAM> Uncle Bob has 3 rules: 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. It feels oversimplification because isn't it circular? Code does what tests test and tests test what code does. The rules do not tell how to break out of that circle and to achieve that the code does what actual product (that we are likely supposed to write) should do. Is it assumed as granted to happen somehow? |
| Cholo Lennon <chololennon@hotmail.com>: Feb 15 04:20PM -0300 On 02/15/2016 10:42 AM, Gert-Jan de Vos wrote: > You might be interested to read these articles on TDD by a well respected author. He elaborates on several downsides of TDD here: TDD is not the same thing as writing unit tests. > http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf > http://www.rbcs-us.com/documents/Segue.pdf I do not agree with the author. Unit tests are really useful tools, specially for library developers Regards -- Cholo Lennon Bs.As. ARG |
| Wouter van Ooijen <wouter@voti.nl>: Feb 15 09:31PM +0100 Op 15-Feb-16 om 7:55 PM schreef Öö Tiib: > Uncle Bob has 3 rules: > 1. You are not allowed to write any production code unless it is to make > a failing unit test pass. So unit-internal itegrity checking (defensive coding) is 'verboten'? > 2. You are not allowed to write any more of a unit test than is sufficient > to fail; and compilation failures are failures. So sitting back, partioning your problem, and writing tests on the boundaries (in one go, just because your mind is focussed on it) is out?? > 3. You are not allowed to write any more production code than is sufficient > to pass the one failing unit test. Yeah, by now I've got it. So I want to write f(n) -> n+1. Case 1: f(0)==1 int f( int n ){ return 1; } Case 2: f(1) == 2 int f( int n ){ if( n == 1 ) return 2; return 1; } Case 3: f(2) == 3 int f( int n ){ if( n == 2 ) return 3; if( n == 1 ) return 2; return 1; } Wow, I feel productive! Am I getting payed by the lines of code or by the unit tests? Doesn't matter, they go hand in hand, and I can write one each per minute. Better yet, I can write a Python script that generates a pair each millisecond! (But can I write that script non-TDD fashion, please?) *any* methodology that forbids people to sit back and think sucks. Wouter van Ooijen |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 15 11:19PM +0200 On 15.02.2016 20:55, 嘱 Tiib wrote: > break out of that circle and to achieve that the code does what actual > product (that we are likely supposed to write) should do. Is it assumed > as granted to happen somehow? By applying some common sense? Also, in order to write anything, you must have some idea what to write, i.e. there must be some design, either written down or at least in the head in case of purist test-driven-design people (which I do not really advocate). Anyway, the TDD work cycle is meant so that you implement your design step-by-step, testing on each step that you have succeeded. Code is written at each step to make the test working and the step completed, so that you have confidence all the time that you are on the right track. The granularity of the cycle depends on the speed of project rebuild. The hard-core TDD advocates talk about rebuild times in seconds. In C++ rebuilds tend to be pretty slow (some projects which I have to work with take up to 15 minutes for recompiling (a single) source file and (incremental) linking), so the TDD steps must inevitably be larger. The upper limit is set by the abilities of the programmer - how large chunks he can manage without "losing the track". |
| "Öö Tiib" <ootiib@hot.ee>: Feb 15 01:21PM -0800 On Monday, 15 February 2016 22:31:50 UTC+2, Wouter van Ooijen wrote: > > 1. You are not allowed to write any production code unless it is to make > > a failing unit test pass. > So unit-internal itegrity checking (defensive coding) is 'verboten'? Supposedly you can write a test that checks that the defenses hold. > > to fail; and compilation failures are failures. > So sitting back, partioning your problem, and writing tests on the > boundaries (in one go, just because your mind is focussed on it) is out?? Perhaps my bad English ... but why do you sit back (I understand it "relax", "loosen up") while writing tests? I trust both production code and tests need some attention. > Yeah, by now I've got it. > So I want to write f(n) -> n+1. > Case 1: f(0)==1 But that is not unit test? You are not supposed to write any code now by rule 1. <snip> > *any* methodology that forbids people to sit back and think sucks. Oh. I thought "sit back" means loosen up and let your fingers to flow, type lot of crap, fill the internet with it. |
| Ian Collins <ian-news@hotmail.com>: Feb 16 10:25AM +1300 Paavo Helde wrote: > (incremental) linking), so the TDD steps must inevitably be larger. The > upper limit is set by the abilities of the programmer - how large chunks > he can manage without "losing the track". My usual answer to that problem is "throw more hardware it"! My trip point for a hardware boost is usually around 30 for a full build... -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 16 10:33AM +1300 Ian Collins wrote: >> he can manage without "losing the track". > My usual answer to that problem is "throw more hardware it"! My trip > point for a hardware boost is usually around 30 for a full build... .. 30 seconds .. -- Ian Collins |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 15 11:34PM +0200 On 15.02.2016 22:31, Wouter van Ooijen wrote: > if( n == 1 ) return 2; > return 1; > } That's exactly what is supposed to happen in TDD if the functionality of the function is complex enough so that you don't see in the beginning that you can solve it by writing "n+1" (figuratively speaking). And that's why there is also the refactoring step in TDD so that when you have obtained some more insight after implementing cases 1, 2 and 3 you are now (hopefully) able to rewrite them as "n+1". And that's why there are tests in TDD, so that you can rerun them after refactoring to ensure you have not broken anything accidentally. > *any* methodology that forbids people to sit back and think sucks. I'm pretty sure TDD does not forbid thinking. At most it warns about over-thinking. Over-thinking means you get stuck because you are not able to figure out "n+1" beforehand, but also refuse to start with a simpler approach which only works in limited cases. I am certain there are people and projects where TDD is not useful, but I am also sure there are people and projects where it makes sense. |
| Wouter van Ooijen <wouter@voti.nl>: Feb 15 10:40PM +0100 Op 15-Feb-16 om 10:34 PM schreef Paavo Helde: > And that's why there is also the refactoring step in TDD so that when > you have obtained some more insight after implementing cases 1, 2 and 3 > you are now (hopefully) able to rewrite them as "n+1". But why aren't I allowed to do that in the first place? > simpler approach which only works in limited cases. > I am certain there are people and projects where TDD is not useful, but > I am also sure there are people and projects where it makes sense. That I can totally agree on. But Uncle Bob doesn't seem to admit that there are *any* projects where TDD is not useful. Or am I misunderstanding him? Wouter |
| "Öö Tiib" <ootiib@hot.ee>: Feb 15 01:40PM -0800 On Monday, 15 February 2016 23:20:06 UTC+2, Paavo Helde wrote: > must have some idea what to write, i.e. there must be some design, > either written down or at least in the head in case of purist > test-driven-design people (which I do not really advocate). Yes, that part was what I thought as missing. May be they have piles of analysts/architects who feed them with very detailed specifications what to code? Such people seem rare here around. > step-by-step, testing on each step that you have succeeded. Code is > written at each step to make the test working and the step completed, so > that you have confidence all the time that you are on the right track. Yes I understand it well. I was wondering from where that design is supposed to emerge? Programming languages are sort of formal software design languages. > (incremental) linking), so the TDD steps must inevitably be larger. The > upper limit is set by the abilities of the programmer - how large chunks > he can manage without "losing the track". I typically do not rebuild the whole product. Only the unit that I write and its tests, that really takes seconds usually. Large product takes sometimes long time to link alone. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 15 11:45PM +0200 On 15.02.2016 23:33, Ian Collins wrote: >> My usual answer to that problem is "throw more hardware it"! My trip >> point for a hardware boost is usually around 30 for a full build... > .. 30 seconds .. The MSVC linker is single-threaded so adding more CPU cores would not help, and clock speeds are not doubling each 18 months any more unfortunately. Not that I am blaming the MSVC linker though, we should really split up that 100MB DLL behemoth. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 15 06:21PM Brian, Pack it in. Wikipedia is an encyclopaedia not a free advertising platform. 1) It is a conflict of interest for the author of a product to modify an encyclopaedic entry so that it mentions that product. 2) In a situation such as this a product has to be notable for it to appear on Wikipedia and your product is not notable (if it was it would have at least one independent, notable third party source discussing it). 3) You are not adding any value to the encyclopaedic entry as what you are doing is purely advertisement for the purposes of promoting your product. 4) You seem to think that as your product is a "free service" you can advertise it at will on Wikipedia. This is an erroneous thought. Again, pack it in. You are acting like a child: people shouldn't have to keep checking the entry to undo your repeated spam edits. /Flibble |
| Christian Gollwitzer <auriocus@gmx.de>: Feb 15 08:32PM +0100 Am 15.02.16 um 19:21 schrieb Mr Flibble: > [...] > Again, pack it in. You are acting like a child: people shouldn't have > to keep checking the entry to undo your repeated spam edits. Maybe an administrator could block the article until the repeated advertisement stops? It should be evident to anyone from a quick google search that Brian's software is nothing widely known/applied. Unfortunaly, I don't have much experience with Wikipedia's processes, how do you call in an admin? Christian |
| woodbrian77@gmail.com: Feb 15 01:37PM -0800 On Monday, February 15, 2016 at 12:21:34 PM UTC-6, Mr Flibble wrote: > Again, pack it in. You are acting like a child: people shouldn't have > to keep checking the entry to undo your repeated spam edits. > /Flibble Sorry if you find it spam. I think it's a case of "One man's trash is another man's treasure." I think the Java section of the Wikipedia page should be cut from 16 lines to 5 or 6 lines. It would also be helpful if the languages were ordered in chronological or alphabetical order. Brian Ebenezer Enterprises - "If I am not for myself who will be for me? If I am only for myself, who am I?" Rabbi Hillel http://webEbenezer.net |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 15 10:42PM +0100 On 2/15/2016 8:32 PM, Christian Gollwitzer wrote: > search that Brian's software is nothing widely known/applied. > Unfortunaly, I don't have much experience with Wikipedia's processes, > how do you call in an admin? I don't know. Wikipedia appears to have evolved to the kind of half-closed society where an unreasonable investment of time and effort is required just to get into it. https://en.wikipedia.org/wiki/Serialization Looks clean now but I notice in the edit history Brian is really persistent about promoting his software there. As if there's no listing of C++ libraries anywhere, not even one automatically posted to the newsgroups every month. Cheers, - Alf |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 14 06:41PM -0500 On 2/14/2016 6:22 PM, Geoff wrote: > communicate with a localhost socket, it communicates with the user's > own mail server using his own client under his control and under his > own credentials. mailto: only works in a program which understands it (i.e. a browser). Unless he builds support for it into his program, it will not work. He will have to determine what the default mail client is and invoke it from his program. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 14 11:43PM On Sun, 14 Feb 2016 15:22:43 -0800 > communicate with a localhost socket, it communicates with the user's > own mail server using his own client under his control and under his > own credentials. Yes, I agree that if they have that mimetype set up, that would indeed work for the purpose of bringing up the mail client. The OP's problem is getting his text form (the order message he referred to) into the client. Is there a standard means of doing that? (I am not saying there isn't, but I am not sure I have seen that when I have sent emails that way myself). Chris |
| Ian Collins <ian-news@hotmail.com>: Feb 15 01:06PM +1300 Jerry Stuckle wrote: > Incorrect. Many MTAs are configured to accept mail from other MTAs with > static IPs, but reject mail from dynamic IPs. It has nothing to do with > being able to send mail from a regular mail client. I don't know about your part of the world, but here most customers are on a dynamic IP. ISPs will accept incoming SMTP traffic from their dynamic IP range. If they didn't, customers wouldn't be able to send mail, would they? -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 14 06:37PM -0500 On 2/14/2016 6:09 PM, Ian Collins wrote: >> the U.S. > As Chris said, "Most consumer users set up their mail client to forward > mail directly to their ISP's SMTP mail relay". I know what Chris said. I was addressing his point of using a mail program on localhost. It will not work on many ISP's. >> email from hosts using dynamic IP addresses. > Except those to their mail relay, otherwise customers wouldn't be able > to send mail from a regular mail client. Incorrect. Many MTAs are configured to accept mail from other MTAs with static IPs, but reject mail from dynamic IPs. It has nothing to do with being able to send mail from a regular mail client. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Geoff <geoff@invalid.invalid>: Feb 14 05:33PM -0800 On Sun, 14 Feb 2016 23:43:22 +0000, Chris Vine >(I am not saying there isn't, but I am not sure I have seen that when I >have sent emails that way myself). >Chris In Windows, I'd put the URL into a dialog box, such as a Help dialog or in an Order Something dialog opened from the Help menu item. I'd do it the same in OSX and the equivalent in Linux dialogs. The OP hasn't stated his target OS but I suspect it's Linux. A standard way to do it? I'm not so sure. I know this works in Windows: system("start mailto:yourname@example.com?subject=Order&body=Order%20details%20here"); I think the equivalent is system("exec mailto:yourname@example.com?subject=Order&body=Order%20details%20here"); but I haven't tested this. |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 14 09:40PM -0500 On 2/14/2016 7:06 PM, Ian Collins wrote: > on a dynamic IP. ISPs will accept incoming SMTP traffic from their > dynamic IP range. If they didn't, customers wouldn't be able to send > mail, would they? That's right. Same here. However, ISPs will accept traffic from *AUTHORIZED* users. They do not accept traffic from non-authorized users which are not for their domain(s). And MTAs from other domains are NOT authorized users. You obviously have no idea how to properly configure an MTA. I hope you never do - your concept is known as a spam relay. But coming from you, that doesn't surprise me in the least. -- ================== 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