- TDD considered harmful - 19 Updates
- Unit testing (Re: Putting project code in many different files) - 6 Updates
| leigh.v.johnston@googlemail.com: Feb 02 04:12AM -0800 One cannot simply change a private method to a public one at snap of fingers because private methods are allowed to break class invariants. |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 04:35AM -0800 On Tuesday, 2 February 2016 12:12:23 UTC, leigh.v....@googlemail.com wrote: [...] > One cannot simply change a private method to a public one at snap of fingers because private methods are allowed to break class invariants. You did not get what I said. I said that it is technically possible to do that, not that it is a sensible or even necessary thing to do. The point is that the keyword "private" does not grant any particular safety, compared to any other syntactical convention. Defining a "private" method in C++ is not different from defining a public method in JavaScript/Python with a tag on it reading "please, mr programmer, don't call it". The access specifiers in C++ and similar languages only define a contract for the external user, they are not meant to "lock" the class from external intrusion. Anyone is technically able to change a private method to public, having the source code. You just don't do it, because you'd change the contract (which keeps the class invariants safe). |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 04:42AM -0800 On Monday, 1 February 2016 17:08:15 UTC, Mr Flibble wrote: [...] > I repeat my original point: TDD is NOT about keeping public methods to a > minimum; it is about creating lots of individually testable public > methods hence it is the enemy of encapsulation and good design. Wrong. TDD is about creating a number of testable INTERFACES, not "creating lots of individually testable public methods". That's your idiotic interpretation of TDD. TDD is based upon something that is not different from what we do in Electronics. If you have a component X that integrates components A, B and C, you test those three components' behaviours separately, and once you know they work, you assemble them and test X's behaviour. Any class encapsulates a number of behaviours. Each behaviour has to be componentized and tested separately. The class invariants are kept safe by assembling the components implementing those behaviours in a specific way and not making the integrated behaviour modifiable - the same way you encapsulate electronic components within other components. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 02 01:25PM On Tue, 2016-02-02, Zaphod Beeblebrox wrote: > compiler enforces that check. But anyone wants to change the > contract, can do that, so it's not different than just a syntactic > convention. That's a funny way of looking at it ... anyone can edit any program to say what they want; that doesn't mean private: is just a convention. However: > 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. I disagree with your wording, but I agree with your point. IME, the conventions in Python are almost as good as private: in C++, if you stick strictly to the conventions (which I think people generally do). (The difference is in Python I have to trust the users of my class not to be stupid, or perhaps run a linting tool. In C++ I can pretty much look at a class and tell that noone is messing with the privates, because it would be not only stupid but remarkably stupid for them to do so.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 05:41AM -0800 On Tuesday, 2 February 2016 13:25:26 UTC, Jorgen Grahn wrote: [...] > That's a funny way of looking at it ... anyone can edit any program to > say what they want; that doesn't mean private: is just a convention. That's a straw man, dude. I never said that "private" does not mean private. I said quite the opposite: I said that "private" DOES mean that the method is private, but it's not different from putting an underscore in front of a method and ASSUMING it is private. Private/public/protected are just conventions. They define a contract. The original objection of the troll was "Any language that doesn't offer private methods". That's stupid. ANY language can offer private methods by means of convention. > conventions in Python are almost as good as private: in C++, if you > stick strictly to the conventions (which I think people generally do). Conventions in Python are better than in C++, cause they are not reinforced by the compiler. Any class can be designed in a wrong way. A method that should be public is instead private. Python does not need the owner of that code to change it, before you can use it. You can call the method anyway, and then get the fixed version of that class. > (The difference is in Python I have to trust the users of my class You have to trust the user of your C++ code too. If you provide them the source code for your class, as I said, anyone is technically able to change your "private" to "public" and use the method anyway. > look at a class and tell that noone is messing with the privates, > because it would be not only stupid but remarkably stupid for them to > do so.) The point is that there's no difference with those language that do not enforce the access specifiers at compile time. It's just a matter of convention. |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 10:02AM -0500 On 2/2/2016 5:58 AM, Zaphod Beeblebrox 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. Nope. I didn't need to test the individual components in my last project (an audio generator). I put it together, hooked a scope up to the output and turned it on. I got the expected output, within both amplitude and frequency tolerances. I didn't check *any* components. Do you check that every expression in your code works properly? Or do you see if the function does what it's supposed to? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Cholo Lennon <chololennon@hotmail.com>: Feb 02 12:17PM -0300 On 02/02/2016 09:42 AM, Zaphod Beeblebrox wrote: > the components implementing those behaviours in a specific way and > not making the integrated behaviour modifiable - the same way you > encapsulate electronic components within other components. I thing you are wrong too. TDD is an iterative process where you must find the solution through that iteration. Defining testable interfaces is just a consequence. People often confuse TDD with writing/designing unit tests. TDD *is* a development process, it's an alternative way of attacking a problem resolution. From wikipedia (https://en.wikipedia.org/wiki/Test-driven_development): "Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards" The process is explained here: https://en.wikipedia.org/wiki/Test-driven_development#Test-driven_development_cycle Of course, testable components are more difficult to develop because encapsulation must be broken in order to made rigorous tests (friend access in C++, package access in Java, dependency injection, etc). Regards -- Cholo Lennon Bs.As. ARG |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 08:51AM -0800 On Tuesday, 2 February 2016 15:02:57 UTC, Jerry Stuckle wrote: [...] > project (an audio generator). I put it together, hooked a scope up to > the output and turned it on. I got the expected output, within both > amplitude and frequency tolerances. I didn't check *any* components. You are either trolling or not able to understand a very simple concept. The reason why you did not have to test the individual components in your project is only because you were taking for granted that the company producing those components had tested them and they were perfectly working. The design for each of those components WAS individually validated. It's similar to using a library in your project: you don't test that Boost works, you take it for granted. I am talking about YOUR OWN code. If you had to design each components in your project yourself, you would HAVE to test each component individually, before assembling them. > Do you check that every expression in your code works properly? Or do > you see if the function does what it's supposed to? I check that all the code that *I* *write* works. Not all the code that I *use*. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 02 04:58PM On Mon, 2016-02-01, Cholo Lennon wrote: >> TDD is the totally wrong approach to software development. Design > > first, implement second and unit test third. > I agree with you. And I kind of agree ... > C++/Java/Python I'am still unconvinded. The teacher explained that TDD > avoids "analysis paralysis" (get stuck in a problem due to overthinking > it). It's true that when you sketch on some unit tests, you may discover that your interface or implementation doesn't have to be that grandiose, after all ... > You have to think the problem on the fly, try, fail, fix... but > IMO most of the time thinking in advance, solves the problem more > quickly and with a better design. I have never tried by-the-book TDD, but I've noted that when I spend much energy on the unit tests, I spend less on getting the implementation itself right. Then after a while I discover that I cannot tell if it's correct or not, and having the unit tests doesn't help because I would need to find out how complete /they/ are ... OTOH, I believe unit testing in general is a wonderful tool; I use it in several different ways. But I avoid TDD (and make a point to not use the phrase to describe what I do). A discussion here last year between me and Ian Collins makes me think it's a personality or education thing -- that TDD suits some people, but not others. I'm more into reading my code to convince myself it correctly implements its interface. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 09:02AM -0800 On Tuesday, 2 February 2016 15:18:03 UTC, Cholo Lennon wrote: [...] > I thing you are wrong too. Let's see. I've been applying TDD for quite a while now, so hardly so, but maybe you're right. >TDD is an iterative process where you must find the solution through that iteration. Defining testable interfaces is just a consequence. I don't understand your point. In order to write testable code, you HAVE to define testable interfaces. The iteration you are talking about is just the red-green-refactor process, which is at the foundation of TDD. > TDD *is* a development process TDD is also a DESIGN process. Many call it test-driven design, and they're right in doing so. TDD drives a much more modular design, which often corresponds to a much better design. I am not saying anything new. There are many articles about TDD around highlighting the better design deriving from it. > Of course, testable components are more difficult to develop because > encapsulation must be broken in order to made rigorous tests (friend > access in C++, package access in Java, dependency injection, etc). You don't have to break absolutely anything. The fact that encapsulation breaks, when writing individual testable components, is a misconception. To build an electronic circuit, you can use resistors, capacitors, diodes, transistors, integrated circuits, etc.. Each of those has been tested individually. The way you assemble them forms the specific "behaviour" you want to implement. You're not breaking the encapsulation of your own circuit, assembling those components in a specific way. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 02 05:04PM On 02/02/2016 11:03, Zaphod Beeblebrox 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 Nevertheless TDD is anathema to best (SOLID) practices related to the design of non-trivial software systems. /Flibble |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 02 05:06PM On 02/02/2016 12:42, Zaphod Beeblebrox wrote: >> minimum; it is about creating lots of individually testable public >> methods hence it is the enemy of encapsulation and good design. > Wrong. TDD is about creating a number of testable INTERFACES, not "creating lots of individually testable public methods". That's your idiotic interpretation of TDD. TDD is based upon something that is not different from what we do in Electronics. If you have a component X that integrates components A, B and C, you test those three components' behaviours separately, and once you know they work, you assemble them and test X's behaviour. Any class encapsulates a number of behaviours. Each behaviour has to be componentized and tested separately. The class invariants are kept safe by assembling the components implementing those behaviours in a specific way and not making the integrated behaviour modifiable - the same way you encapsulate electronic components within other components. Wrong. TDD is about creating the smallest possible unit, initially failing, that must then be fixed during that iteration and this unit may or may not be an interface. /Flibble |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 09:07AM -0800 On Tuesday, 2 February 2016 17:04:49 UTC, Mr Flibble wrote: [...] > Nevertheless TDD is anathema to best (SOLID) practices related to the > design of non-trivial software systems. No, it's not. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 02 05:07PM On 02/02/2016 13:41, Zaphod Beeblebrox wrote: > Conventions in Python are better than in C++, cause they are not reinforced by the compiler. Any class can be designed in a wrong way. A method that should be public is instead private. Python does not need the owner of that code to change it, before you can use it. You can call the method anyway, and then get the fixed version of that class. Wrong. C++ is better (and safer) than Python simply because it makes it harder to call a private method by mistake. /Flibble |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Feb 02 09:08AM -0800 On Tuesday, 2 February 2016 07:40:39 UTC, Öö Tiib wrote: [...] > "Agile" basically means "using two-week waterfalls". No, it doesn't. Why don't you all grab a book and start studying what you don't know, rather than rambling idiocies in a ng? |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 02 05:09PM On 02/02/2016 12:35, Zaphod Beeblebrox wrote: > [...] >> One cannot simply change a private method to a public one at snap of fingers because private methods are allowed to break class invariants. > You did not get what I said. I said that it is technically possible to do that, not that it is a sensible or even necessary thing to do. The point is that the keyword "private" does not grant any particular safety, compared to any other syntactical convention. Defining a "private" method in C++ is not different from defining a public method in JavaScript/Python with a tag on it reading "please, mr programmer, don't call it". The access specifiers in C++ and similar languages only define a contract for the external user, they are not meant to "lock" the class from external intrusion. Anyone is technically able to change a private method to public, having the source code. You just don't do it, because you'd change the contract (which keeps the class invariants safe). C++ makes it harder to fuck up than with Python which is just one reason why C++ is far superior to Python the latter being not much better than a toy language in my opinion. /Flibble |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 02 05:10PM On 02/02/2016 16:51, Zaphod Beeblebrox wrote: >> the output and turned it on. I got the expected output, within both >> amplitude and frequency tolerances. I didn't check *any* components. > You are either trolling or not able to understand a very simple concept. Anyone who disagrees with you is a troll it seems. /Flibble |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 02 05:17PM On 02/02/2016 17:02, Zaphod Beeblebrox wrote: > I don't understand your point. In order to write testable code, you HAVE to define testable interfaces. The iteration you are talking about is just the red-green-refactor process, which is at the foundation of TDD. >> TDD *is* a development process > TDD is also a DESIGN process. Many call it test-driven design, and they're right in doing so. TDD drives a much more modular design, which often corresponds to a much better design. I am not saying anything new. There are many articles about TDD around highlighting the better design deriving from it. Test Driven Design is egregious. You cannot design non-trivial software systems with good quality by trial and error fixing failing test cases; not only is it more inefficient as a process then formal up-front design with periodic design reviews (with associated re-factoring) the resultant design (and implementation) will not be thought through, will be difficult to understand and maintain and it will be, in a word, slapdash. If you use Test Driven Design to design your software I cannot imagine how bad your output actually is. I wouldn't touch your software with a bargepole mate. /Flibble |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 12:23PM -0500 On 2/2/2016 11:51 AM, Zaphod Beeblebrox wrote: >> amplitude and frequency tolerances. I didn't check *any* components. > You are either trolling or not able to understand a very simple concept. > The reason why you did not have to test the individual components in your project is only because you were taking for granted that the company producing those components had tested them and they were perfectly working. The design for each of those components WAS individually validated. It's similar to using a library in your project: you don't test that Boost works, you take it for granted. I am talking about YOUR OWN code. If you had to design each components in your project yourself, you would HAVE to test each component individually, before assembling them. No, component manufacturers don't test every individual component that comes off the line. Capacitors which cost less than $0.01 to make and have a failure rate of less than 0.0001% aren't worth testing. The same is true with many IC's. Some, like microprocessors, cost more and have a higher failure rate, so each one is tested. >> Do you check that every expression in your code works properly? Or do >> you see if the function does what it's supposed to? > I check that all the code that *I* *write* works. Not all the code that I *use*. That isn't what I asked. You create expressions. Do you test every expression that you write, to ensure it works properly? That would be the coding equivalent of testing every electronic part. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: Feb 02 12:29PM +0100 On 02/02/16 10:31, Ian Collins wrote: >> 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! That follows naturally. To get a correct working system, you need correct specifications and a correct implementation of those specifications (testers are not needed for correctness). So if the developers are doing a perfect job, any problem lies with the specifications. Conversely, if the specifications are perfect, any problems lie with the developer. The usual case is that both have imperfections, and that's why you have testers to help spot the problems. |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 09:48AM -0500 On 2/2/2016 4:27 AM, Paavo Helde wrote: > 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. That is true, but a good design limits refactoring. > 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. No arguments - these things happen all the time. Any large project I've worked on has had scope creep. But that makes a design even more necessary. When you get the scope creep, you can look at your design and see exactly what needs to be changed. It's like the blueprint for a house. Let's say you start building a house for someone. Partway into the building, the customer comes back and say "I need a master bath with sauna". The original plans didn't have a master bath. So you go back to the plans, and work on how to make room for that bath. However, you also need plumbing and electricity. And as you did deeper, you find you need a vent fan, which then requires wiring and ducting in the attic. You probably also will need to put a furnace vent in that bathroom. Without a blueprint, it would be difficult to pick up on all of these things. For instance, you might have the drywall up before you realize you need the furnace vent. Or you might run the electric - then find out you have a conflict with the plumbing. But the design also ensures you change *only* what needs to be changed. The same is true with programming. A good design gets you going. But it also shows you what needs to be changed when scope creep occurs. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 09:48AM -0500 On 2/2/2016 2:15 AM, Gareth Owen wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: >> I don't need to do any research on it. I've seen it tried. > Ladies and Gentlemen, Donald Trump Ladies and Gentlemen, trolling noob. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 09:49AM -0500 On 2/2/2016 2:18 AM, Gareth Owen wrote: >> nothing less. > Oh, the irony. > Thanks Donald, you've provided some good chuckles. You're welcome, trolling noob. But to be compared to a very successful businessman is an honor. Thank you, even though your are a trolling noob. You should be so successful. At least he knows what he's doing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 09:56AM -0500 On 2/2/2016 4:11 AM, David Brown wrote: > 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. Developers (at least good ones) get paid a lot more than testers, and their time is wasted performing tests. And while their code is being tested, the developers are on to other things. They are not just waiting for feedback. That doesn't mean the developer should just get a clean compile and send the code off (although I have had managers say exactly that). They can do limited testing - but very limited. They need to be writing code. > 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. No, the developer's job is to write code that works. The test group's job is to find ways to break that code. Two entirely opposite approaches, and the biggest reason why the developers shouldn't be testing the code. Additionally, the developers will test the code *as written*. They can't help but do so, since they are intimately familiar with the code. The test group will test the code *as designed*, to ensure that it meets the requirements. Again, two different approaches. And this testing can find things the developer missed - and therefore didn't test for. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: Feb 02 04:40PM +0100 On 02/02/16 15:56, Jerry Stuckle wrote: > job is to find ways to break that code. Two entirely opposite > approaches, and the biggest reason why the developers shouldn't be > testing the code. In the interests of winding down this thread, I am not going to bother with a detailed reply. Suffice it to say that I think you are wrong, but it is not worth my effort trying to correct you - you apparently have a total inability to learn from discussions like this. If I thought anyone else was taking your ideas seriously then I might elaborate for their benefit, but I doubt if it is necessary in this thread. I expect that will leave me labelled as a "noob", whatever that might actually mean. It will probably also classify me as a "troll", which does not mean what you think it means. But I have been called worse on Usenet, and I will not loss sleep over it. |
| 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