| 4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 31 06:42PM On 30/01/2016 22:28, Jerry Stuckle wrote: [...] > It does matter, and it's not at all unusual for a class to have other > classes as members. You start out testing single classes. Then you can > test classes which include the first class. No, it doesn't matter in the least. Tests are normally executed in 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. >> running the tests contained in SomethingTest.cpp? > Please read the thread. We are talking about when there are multiple > classes in one file. My question stands. -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra) |
| Ian Collins <ian-news@hotmail.com>: Feb 01 01:03PM +1300 Jerry Stuckle wrote: > Now you create the independent class and test it. The dependent class > now fails tests because the mock independent class didn't perform the > proper actions. So you didn't implement your mock correctly, go back and fix it. > the real independent class instead of the mock one. You have now wasted > programmer and test group time by having to rewrite "working" code, and > introduced the possibility of even more bugs. You have wasted time implementing a mock that didn't do what it said on the tin. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 31 09:52PM -0500 On 1/31/2016 7:03 PM, Ian Collins wrote: >> now fails tests because the mock independent class didn't perform the >> proper actions. > So you didn't implement your mock correctly, go back and fix it. And how do you know if it is implemented correctly if it isn't the full class? >> introduced the possibility of even more bugs. > You have wasted time implementing a mock that didn't do what it said on > the tin. No, you have wasted time implementing a mock which doesn't perform the same as the real unit. Tell me - how is your mock class going to do the same work as the real class if it isn't the real class? It's a lot more than just returning a value from a method call. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| 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: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: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:42PM -0500 On 1/31/2016 6:34 PM, Ian Collins wrote: > So how do you get one of B's methods to throw an out of memory > exception? Or a <you name it> exception? Or return the result you > expect it to return after 100 calls? The same way you would in production - you create the scenario where the exception would occur, and cause it. If it's impossible to test, then it's impossible for the scenario to occur in production, anyway. And if you expect a specific return after 100 calls, then you call it 100 times. Anything that can happen in production can be tested for. Whether you test for the extreme cases or not is up to you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Feb 01 12:34PM +1300 Jerry Stuckle wrote: > 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. So how do you get one of B's methods to throw an out of memory exception? Or a <you name it> exception? Or return the result you expect it to return after 100 calls? -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 01 05:04PM +1300 Jerry Stuckle wrote: >>> it's impossible for the scenario to occur in production, anyway. >> So you consume all of the memory on your test box, what then? > Then you test. On a shared development system? Yeah right. >>> 100 times. >> ..and if each call would fetch and parse a file from the internet? > Then it fetches and parses a file from the internet. Evey one of the dozens or hundreds of times a day you run your unit tests? > If a unit test trashes the host or creates a DOS attack on a remote > server, then the test is incorrect or the class fails. If it can happen > during testing, it can happen during production. I don't think you understand the concept of layered testing. The topic of this discussion has been unit testing, not acceptance or system testing. The code being tested may not even be targeted at the system you are developing on (especially if you are unit testing embedded code). The development may not even have access to the devices that are feeding data into the code under test. You have to mock. -- Ian Collins |
| 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> |
| 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: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. |
| 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. |
| 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 ================== |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 02 08:06PM +0200 On 2.02.2016 16:48, Jerry Stuckle wrote: > 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. I am starting to have a feeling that much of the activity I call refactoring, you are calling design review. I guess the things can be done this way as well, I just have never seen so detailed design specifications. In software, having the sauna with certain parameters like temperature, humidity, etc is a feature visible to the end user. How the pipes and wires are connected is an implementation detail and does not concern the end user, as long as a couple of rules are followed. If you specify too much implementation details in the blueprint, then it becomes tedious to follow and update. Amusingly, this is exactly how the blueprints are often made nowadays. Blueprints for electricity installments for example specify things like: 2 ordinary wall sockets in this wall, 1 3-phase socket in the garage, etc. It's up to the electrician to install wires as he sees fit, following some general rules. When he is ready, a photo is taken of each wall which documents the location of wires for any case before they are covered up. |
| Ian Collins <ian-news@hotmail.com>: Feb 03 03:18PM +1300 Jerry Stuckle wrote: > Yes, I know about them. But you've already proven you don't understand > proper project management or design, so I'm not going to waste my time > trying to explain why they aren't the entire answer. We all know that you wouldn't be able... > There's an old adage - "Never teach a pig to sing. It wastes your time > and annoys the pig.". I'm not going to try to teach the pig to sing. Jolly good. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 08:05PM -0500 On 2/2/2016 3:57 PM, Ian Collins wrote: >> which can terminate the test - and finally, evaluate the results. > There is software to do all of the donkey work known as unit test > frameworks. Read up on them and you might learn something. There's an old adage - "Never teach a pig to sing. It wastes your time and annoys the pig.". I'm not going to try to teach the pig to sing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Feb 03 09:37PM +1300 David Brown wrote: >> someone screwed up the repo accidentally. > I don't know what sort of version control system you use, but it sounds > medieval - perhaps it was MS "Source Safe" ? I get the impression from what he has posted in this thread and his general lack of development process insight that he last coded in the 80s. Or maybe he has just read some rather old books. -- Ian Collins |
| Gareth Owen <gwowen@gmail.com>: Feb 03 01:45PM > I get the impression from what he has posted in this thread and his > general lack of development process insight that he last coded in the > 80s. At the very least, that's whe he stopped *thinking* and his opinions about best-practice ossified into his own peculiar set of facts. |
| Gareth Owen <gwowen@gmail.com>: Feb 03 02:35PM > Grow up, both of you. Just walk away. But I enjoy prodding bloviating windbags! |
| David Brown <david.brown@hesbynett.no>: Feb 03 04:23PM +0100 On 03/02/16 15:35, Gareth Owen wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> Grow up, both of you. Just walk away. > But I enjoy prodding bloviating windbags! That is perhaps okay up to a point - and fully understandable in this case. But it quickly gets pointless, and c.l.c. has already had a couple of threads dominated by Jerry and another nitwit repeatedly calling each other trolls. Your Donald Trump reference /was/ witty, IMHO, but now is the time to leave his posts unanswered (unless you are supplying useful technical information for the rest of us, of course). |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 03 06:58PM +0200 On 3.02.2016 18:08, Jerry Stuckle wrote: > You didn't answer my question. What happens if you delete a file from > the repo? Revert the last commit? > Who said anything about a .zip file? These are repos. svn or git? |
| scott@slp53.sl.home (Scott Lurndal): Feb 03 06:07PM >Revert the last commit? >> Who said anything about a .zip file? These are repos. >svn or git? or cvs or rcs or sccs or clearcase or bitkeeper or perforce? |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 03 08:43PM +0200 On 3.02.2016 20:07, Scott Lurndal wrote: >>> Who said anything about a .zip file? These are repos. >> svn or git? > or cvs or rcs or sccs or clearcase or bitkeeper or perforce? You missed at least visual sourcesafe and mercurial. Anyway, I trust that all these are able to revert a deleted file, so Jerry's "repo" must be something else. Probably predating sccs (which was released in 1972). Cheers Paavo |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 10:51AM -0500 On 2/3/2016 3:37 AM, Ian Collins wrote: > I get the impression from what he has posted in this thread and his > general lack of development process insight that he last coded in the > 80s. Or maybe he has just read some rather old books. I just finished a project with over 30 programmers last October. It was quite successful, coming in under budget and before the deadline. -- ================== 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