- TDD considered harmful - 8 Updates
- Unit testing (Re: Putting project code in many different files) - 5 Updates
- Triple vodka - 1 Update
- Minecraft - 1 Update
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 31 09:20PM On 31/01/2016 18:45, 4ndre4 wrote: > On 30/01/2016 23:11, Mr Flibble wrote: >> If you eschew private methods and instead make everything public > That's not what TDD is. Sure it is. /Flibble |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 31 09:23PM On 31/01/2016 18:55, 4ndre4 wrote: > you can build with them. Remember that there are languages (such as > Python, JavaScript, etc..) where there is no concept of "private > method". Private methods are just a convention. You obviously don't understand class invariants. Any language that doesn't offer private methods doesn't offer a way to easily enforce a class invariant: no public method can break a class invariant by definition. Such languages are at best toy and at worst harmful (just like TDD). Python and JavaScript are both toy. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Feb 01 10:51AM +1300 Mr Flibble wrote: > Python and JavaScript are both toy. Yeah right. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 01 11:03AM +1300 Mr Flibble wrote: > wants lots of testable small (atomic) public methods to test but every > public method you add actually REDUCES the encapsulation of a class > whilst adding a private method does not sausages. Er no, TDD doesn't want anything of the sort. Being a process, TDD doesn't actually "want" anything at all except for tested, working code... If you understood the process, you would know that there isn't any conflict between TDD and encapsulation. -- Ian Collins |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 31 11:06PM On 31/01/2016 22:03, Ian Collins wrote: > doesn't actually "want" anything at all except for tested, working code... > If you understood the process, you would know that there isn't any > conflict between TDD and encapsulation. I do understand the process: private methods are untestable so should be avoided in TDD land ergo encapsulation is increased when adding more testable public methods. TDD is the enemy of both encapsulation in general and C++ in particular. /Flibble |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 01 01:17AM +0200 On 1.02.2016 1:06, Mr Flibble wrote: > avoided in TDD land ergo encapsulation is increased when adding more > testable public methods. TDD is the enemy of both encapsulation in > general and C++ in particular. Private methods are untestable only if they are never called by the public methods. TDD tests the features and does not care how the class provides these features. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 31 11:17PM On 31/01/2016 23:17, Paavo Helde wrote: > Private methods are untestable only if they are never called by the > public methods. TDD tests the features and does not care how the class > provides these features. Meh. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 31 11:21PM On 31/01/2016 23:17, Mr Flibble wrote: >> public methods. TDD tests the features and does not care how the class >> provides these features. > Meh. TDD wouldn't so bad if it wasn't ALSO an acronym for Test Driven DESIGN which is of course total and absolute bollocks. Intelligence not failed unit tests should driver design of non-trivial non-toy systems. |
| Ian Collins <ian-news@hotmail.com>: Feb 01 10:44AM +1300 Jorgen Grahn wrote: >> inheritance. I will always mock an encapsulate class, with inheritance > ^^^ > (I assume you meant "encapsulated" there.) Yes. > I've always figured bar is an implementation detail of Foo; that its > state is part of Foo's state. So I ignore it when I'm testing Foo > (assuming Bar itself doesn't do I/O or something). There's the thing: most of the work I do these days is one or two steps above the operating system interface, so there's a strong chance that Bar will be doing I/O or something. The same degree of separation applies to most embedded systems. > arguing with coworkers about how to proceed with the testing? It's > so frustrating when you only have your own opinions and prejudices > as a starting point. Doesn't anyone have colleagues any more? Sorry, I just hate the term "coworkers"! Back to the topic: what to reuse and what to mock? This is as much a philosophical discussion as a technical one. Going too far in either direction will result in either an incomprehensible mess or under testing. Any project team will have to find their own happy place and where that place lives between the two extremes will depend on the domain and the personalities of the team members. The last team I worked with were all detail focused (pedants if you like) and working on a safety critical control system. This combination naturally led to mocking everything except the class under test. Each class had 5 files associated with it; the header and definition, the test header and tests and the fifth being an (XML) interface description used by the test framework to generate mocks. > Bar to keep. You can also document what happens to Foo if Bar doesn't > keep the contract, but I'm unsure if that has any value. I suspect > you can list better arguments. You gave one below: Another common case is where you want Bar to be in a particular state when the method under test is called. If for example Bar implements a state machine you may have to jump through hoops to get the real Bar into the correct state. > - programming errors (covered by Bar's unit tests) > - incorrect usage (covered by Foo's unit tests) > - memory allocation problems Another case I often have is a function that filters a list of files, say comparing entries from different filesystem snapshots. I want the objects (or system call) that returns the file data to give me the data (file type, size, timestamps) I need for the test. Hope this helps, -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 31 06:09PM -0500 On 1/31/2016 1:14 AM, Ian Collins wrote: >>> A mock of B will behave exactly as the tests define it. >> Which may or may not be the actual behavior of the class. > Which would be pretty f'ing useless. Which is exactly why you wouldn't be using a mock of B. You'd use the real, *tested* B. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 31 06:13PM -0500 On 1/31/2016 2:14 AM, Alf P. Steinbach wrote: > called something else? > Cheers, wondering, > - Alf Alf, What I mean is that A is tested with the real B. If A depends on B, you can't ensure A works properly if you don't have a working B to test with. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 31 06:15PM -0500 On 1/31/2016 2:42 AM, Ian Collins wrote: > either have to pollute B with the code to synthesise a failure, or mock it. > Yes at some point (typically in integration testing) you will be testing > the real code in combination, but for unit testing A, you need to mock B. The behavior of the real B's methods when used with A are the same in testing as in production. If the test requires one of B's methods to fail, then it will fail in both test and production. If it doesn't, you have a problem - in both testing and production. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 31 06:17PM -0500 On 1/31/2016 1:42 PM, 4ndre4 wrote: > random order. The unit tests for class A are supposed to test ONLY the > behaviour for class A and not assume any dependency. If any dependency > is needed, it should be mocked. You cannot properly test a class if behavior of dependent classes is mocked. You cannot ensure the dependent class's behavior will be the same when the real dependency is used. Tests are not in completely random order. Before testing a dependent class, the class it is dependent on requires testing. >> Please read the thread. We are talking about when there are multiple >> classes in one file. > My question stands. Your question is meaningless because it's not part of what we are discussing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| woodbrian77@gmail.com: Jan 31 01:18PM -0800 On Sunday, January 31, 2016 at 2:40:21 PM UTC-6, Daniel wrote: > > to debauchery. Instead, be filled with the Spirit." Ephesians 5:18 > "Drink no longer water, but use a little wine for thy stomach's sake and thine often infirmities." > 1 Timothy 5:23 A little wine is maybe half of a single vodka. Some here seem prone to excess. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 31 08:53AM -0800 On Sunday, 31 January 2016 16:36:43 UTC+2, David Brown wrote: > a startup code enabling the oscillator, waiting for it to stabilise, > then sorting out your PLL's, dividers, clock enables, etc., for all the > different parts of the system. I meant that if more complexities are required to product's external behavior then it is generally cheaper to do same on more powerful and more general purpose architecture. There can be exceptions but basics of those are common, can be reused and so can be even provided as part of API from chip manufacturer. Everybody counts money so if new features provide no benefits then they order and use older version. > greatly reduce the effort. And then you get the boss and/or customer > and/or company salesman saying "since you have such a powerful > microcontroller, let's add /this/ feature to the software..." :-) They know that more features cost more time and effort. If the idea will likely fall short then I may have opportunity to improve on it that we can do something similar that is more useful. Or if it is rare and immediately useful idea then I have opportunity to make a better (more likely winning on market) product. Or if it is bad idea then I have opportunity to explain that our baby carriage does not perhaps benefit from such expensive snowplough but we can try it out of course if we have budget. On very rare case I have the misery to tell that it is impossible (that they may interpret as me being lazy or stupid) and so I am positive hero in eyes of those people. |
| 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