- Triple vodka - 2 Updates
- Let's talk about multiple inheritance and interfaces. - 1 Update
- TDD considered harmful - 1 Update
- Unit testing (Re: Putting project code in many different files) - 4 Updates
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 30 11:16PM Is having a triple vodka a thing? /Flibble |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 31 12:32AM +0100 On 1/31/2016 12:16 AM, Mr Flibble wrote: > Is having a triple vodka a thing? It's a thing++. Cheers!, - Alf |
| "Öö Tiib" <ootiib@hot.ee>: Jan 30 03:21PM -0800 On Saturday, 30 January 2016 19:52:29 UTC+2, 4ndre4 wrote: > I think it would be much more productive (for everyone) if, rather than > using a polemic tone in each message, people explained what they mean > pacifically. Sorry for my tone if it offended anyone. It was worth mentioning, not worth big polemics. RAII ("Resource Acquisition Is Initialization") is one of most basic idioms in C++ programming language. It is worth learning before class inheritance and polymorphism. C++ code that does not follow RAII can still be correct but very often leaks resources or is not exception-safe. Same is perhaps with some other programming languages like Ada and D. I saw your code as a good example how such code leaks resources. > If you mean that my code "leaks" 3 objects because it does > not deallocate them, then nobody really cares. It's just an example to > show how virtual inheritance works. When basic resource management and exception safety are missing from code then it is unusual for me. I see something like that in code of my coworkers very rarely, even if it was only meant as test or demo. So I found it worth mentioning as unusual defect. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 30 11:11PM If you eschew private methods and instead make everything public then it is impossible to maintain a class invariant except WITHIN a SINGLE public method which has the effect that some of your public methods MUST be unnecessarily large/complex. If you don't think about or don't understand class invariants (which I suspect is the case for most TDD adherents) then your existing non-trivial designs really will be god-awful. TDD is the enemy of encapsulation. TDD really is a bad idea. /Flibble P.S. Sausages. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 30 05:31PM -0500 On 1/30/2016 2:01 PM, Paavo Helde wrote: > mocked), not at the later stage when hidden bugs get revealed by any > reason. And this does not contradict putting other classes in the same > file in any way. Testing never stops until the product is ready to ship. Even then, it may not stop. And any time a file is changed, all classes in that file must be tested to ensure there no bugs have been inadvertently introduced. > testing B again, this will be done uncountable times. > Cheers > Paavo Yes, if the testing is automated (and it is in most large projects), that is true. But it still takes time and manpower to ensure the tests get run and to verify the results. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Jan 31 11:33AM +1300 Jerry Stuckle wrote: > test classes which include the first class. > And you can run the tests for class B independent of class A - but since > A is derived from B, you can't test A without knowing B is working. You can, you just use a mock of B. You can't property test A without being able to control the behaviour of the B methods it is using. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 30 05:54PM -0500 On 1/30/2016 5:33 PM, Ian Collins wrote: >> A is derived from B, you can't test A without knowing B is working. > You can, you just use a mock of B. You can't property test A without > being able to control the behaviour of the B methods it is using. But a mock of B may or may not behave the same. Initial tests of A would be OK, but not conclusive, since A's operation depends on B. And the interaction between the two is part of the unit test of A. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Jan 31 12:09PM +1300 Jerry Stuckle wrote: >> You can, you just use a mock of B. You can't property test A without >> being able to control the behaviour of the B methods it is using. > But a mock of B may or may not behave the same. A mock of B will behave exactly as the tests define it. > Initial tests of A > would be OK, but not conclusive, since A's operation depends on B. And > the interaction between the two is part of the unit test of A. Consider the case where B isn't part of the project code but a third part library. -- Ian Collins |
| 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