Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
To mock or not to mock

By mirleid in Technology
Sun Sep 25, 2005 at 06:07:58 PM EST
Tags: Software (all tags)
Software

Being involved in systems development in Java, I follow discussions on tools and techniques for testing code. One particular area of interest is mock-based approaches to unit testing, whereby you create simulacra of objects your code is dependent upon and use them to break dependencies so that you code may be tested in isolation. While going through some conference proceedings, I found this. And it shocked me to no end...


Before we go to the heart of the matter, and for those of you not familiar with the terminology, a bit of background.
  • A unit test is basically something that a developer creates to demonstrate, in a repeatable manner, that the code that he has produced actually works. It normally takes the form of a class that puts the code through its motions in a series of scenarios, and is normally integrated with some form of automated build/verification environment (which are normally provided by tools like Maven). Unit testing is normally accepted to be a form of white box testing.
  • A mock object is an object that looks and feels like the real thing, but isn't. This means that it will expose the same interface as the real thing, will throw exceptions (or signal errors) in the same way as the real thing, but it will not be the real thing, in the sense that it will only mimic the behaviour, not actually implement it for real

There are several mock frameworks out there. The most notable (read: used) of them are MockObjects and JMock. They provide the same basic mechanisms to create mock objects, albeit through a different API.

In the scope of Test First Development, what you normally do is:

    1. Create a test for a chunk of what your implementation class expects to do
    2. Work on your implementation class so that it does what the test expects it to do
    3. Run the test
    4. If the test fails, go back to 2
    5. If the test works, go back to 1 for the next chunk
    6. If all the chunks are there, you're done

Mocks are quite useful in this scenario, since your implementation class will undoubtedly use services from other classes and those might not be available at the time that you are writing your own code. What you do then is to create a mock for the classes that your class uses based on some specification/description of what they do, and use the mock instead. It effectively decouples your work from everybody else's, removing dependencies and allowing you to develop and test in isolation.

This is where the conference article comes in: in it, I find a very interesting description of mock-based development and testing approaches, but at the same time, an endorsement for the (to me) abhorrent practice of hard-coding in your Unit Tests the methods that your class will call.

Assuming that you have a class like the one below providing services to your implementation class

    public class ServiceProvider
    {
        public int provideSomeService(String a)
        {
            ...
            return 10;
        }

        public void provideSomeOtherService(int b)
        {
            ...
        }
    }

and that your implementation class looks like this

    public class MyImplementationClass
    {
        public void someMethod()
        {
            //do some stuff
            sProvider.provideSomeService("b");
            //do some other stuff
        }
    }

what they are saying is that your test class should be like

    public class MyUnitTestClass
    {
        public void testSomeMethod()
        {
            ...
            mockServiceProvider.expect(once()).method("provideSomeService").with (eq("b")).will(returnValue(10));
            ...
        }
    }

While this might be admissible if you are the only one writing code in a given project, I really do not think that hard-coding method names and which methods your class actually calls in your Unit Tests is a good thing, for a number of reasons:

  • You effectively hardcode the method names in strings throughout your testing code base. That means that if somebody changes a method name in a class that is being mocked, your code and Unit Test will still compile fine, but will blow up at run time
  • You effectively hardcode the method signatures into your Unit Test, and those method signatures belong to classes that you are not directly testing. The effect of a signature change is the same as the one mentioned for method name changes (above)
  • Even though Unit Testing is considered to be white box testing, I do not think that this extends to stipulating in your test code exactly what methods your implementation class will be calling when it goes about its business
  • The whole approach is highly flawed in environments where you have relatively large teams producing code and the volume of change is high. Somebody changing the name of a method in some class could cause a whole raft of tests for clients of that class to fail without any good reason (the related method calls would have had to have been changed for the code to compile in the first place)
  • The whole method call checking does not, in my mind, add any substantial value, for all that it is telling you if the method succeeds is that the corresponding methods were called, but it does not tell you anything about the state of the class that you are testing, which ultimately is what you would be interested in.

So, and assuming that you care enough about the subject to have read this far, what is your opinion?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o this
o white box
o mock object
o MockObject s
o JMock
o Test First Development
o Also by mirleid


Display: Sort:
To mock or not to mock | 58 comments (50 topical, 8 editorial, 0 hidden)
I think... (2.00 / 4) (#1)
by BJH on Fri Sep 23, 2005 at 05:49:34 AM EST

...you should program in Visual Basic, where you don't have to worry about that sort of thing.
--
Roses are red, violets are blue.
I'm schizophrenic, and so am I.
-- Oscar Levant

Worry about testing, you mean?[nt] (none / 0) (#2)
by mirleid on Fri Sep 23, 2005 at 05:51:18 AM EST



Chickens don't give milk
[ Parent ]
right (3.00 / 3) (#3)
by speek on Fri Sep 23, 2005 at 09:05:07 AM EST

No one expects a VB program/programmer to get it right, so testing is unnecessary.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Well, in that case... (3.00 / 3) (#6)
by jd on Fri Sep 23, 2005 at 12:55:08 PM EST

Nobody expects the Spanish Inquisition!

[ Parent ]
My approach to mocking (none / 1) (#11)
by MSBob on Fri Sep 23, 2005 at 02:08:07 PM EST

I have a great idea on the whole mocking thing that is very different from the currently used approaches. My idea revolves around using aspects to intercept tested method's external invocations and replace the return values with canned values from the advice. I'm pretty sure it'll work but haven't had the time to build a nice framework around it.
I don't mind paying taxes, they buy me civilization.

Don't need to... (none / 0) (#23)
by mirleid on Sat Sep 24, 2005 at 02:06:23 AM EST

...use something like AspectJ. Doing a piece on AOP has been on my list for some time now, somehow never got around to it...

Chickens don't give milk
[ Parent ]
You don't understand (none / 0) (#27)
by MSBob on Sat Sep 24, 2005 at 06:28:38 PM EST

Of course, I'm not going to write my own aspects framework. As a matter of fact I'm going to use AspectJ because that is the one I like the most. But AspectJ is not enough. There is still room for a framework and an Eclipse plugin to select the method call to mock and generate the required aspect and its advice stubs.

I'm gonna work on it as soon as the release madness cools down a bit at my workplace.

I don't mind paying taxes, they buy me civilization.

[ Parent ]
something like this? (none / 0) (#58)
by themeaton on Wed Nov 23, 2005 at 03:02:10 AM EST

http://www.xprogramming.com/xpmag/virtualMockObjects.htm

[ Parent ]
Nope... (none / 0) (#13)
by mirleid on Fri Sep 23, 2005 at 03:08:40 PM EST

The point of the article is that hard-coding your object interactions (as in, method calls) in your unit test classes is wrong. I think that I did address your earlier comment in the sense that I explain what that line is trying to accomplish (and actually, if anything, the JMock API is self explanatory in that it can have meaning extracted from it if you just read the English words)...

Chickens don't give milk
Apologies... (none / 0) (#22)
by mirleid on Sat Sep 24, 2005 at 01:59:03 AM EST

This was a response to creativedissonance's post that missed its target...Damn alcohol...

Chickens don't give milk
[ Parent ]
not to mock. (2.37 / 8) (#14)
by pb on Fri Sep 23, 2005 at 07:24:46 PM EST

Mocking Java takes very little effort. In fact, it practically mocks itself.
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
(0) Hide - Dumb fucking nigger knows jack shit (1.12 / 8) (#32)
by 0xA736 on Sun Sep 25, 2005 at 03:43:01 PM EST

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

[ Parent ]
What has that got to do with the parent post? nt (none / 0) (#33)
by twanvl on Sun Sep 25, 2005 at 06:01:40 PM EST



[ Parent ]
Holy shit, Sherlock! (2.00 / 2) (#15)
by ksandstr on Fri Sep 23, 2005 at 10:10:20 PM EST

I know some luminaries within the "OO community" have this aversion with hard-coding that borders on the irrational, but... Holy fucking hell! Is that some sort of an elaborate april fools' thing or something? Because I'm not laughing.

This, I think, is the purest form of OO wank: Writing It Once And For All. Going for the most general implementation so that no one will ever have to touch the code again. Overusing reflection (or using it at all) in a C#/Java-style language. Sticking so many tiny classes in a crude mockery of separation-of-concerns in a namespace that your "simple and small" HTTP server package ends up being the 400+ class inscrutable heap of crap, and that's not even counting inner and anonymous classes[1]. That just ain't the way to go, unless you find the idea of running code that is straight off the prototype branch in a production system particularly appealing.

[1] the object-oriented equivalent to spaghetti code, actually. Control flow ends up jumping all over the place mostly just because it can without a reason beyond "well maybe someone will want to do something different in the future, we gotta prepare for that don't we?".

Fin.

Yeah, that's famous in the OO crowd (none / 0) (#16)
by Surial on Sat Sep 24, 2005 at 01:27:07 AM EST

and a despicable habit. But the main point the article raises is of a different nature. See my other comment on this.
--
"is a signature" is a signature.

[ Parent ]
Did you actually read the thing?[nt] (none / 0) (#19)
by mirleid on Sat Sep 24, 2005 at 01:49:00 AM EST



Chickens don't give milk
[ Parent ]
I thought it was called Stubbing (none / 0) (#17)
by QuantumG on Sat Sep 24, 2005 at 01:34:18 AM EST

Stubs being the critical elements of integration testing.

Gun fire is the sound of freedom.
A stub is not a mock... (none / 0) (#20)
by mirleid on Sat Sep 24, 2005 at 01:51:58 AM EST

...although a mock can be used as a stub. See this...

Chickens don't give milk
[ Parent ]
Re: a stub is not a mock, see this... (none / 0) (#39)
by bslade on Mon Sep 26, 2005 at 02:17:55 AM EST

The web page you reference says:

"..the key difference with mocks is the expectation setting mechanism where you test which methods were called on the mock. Mockists often refer to a mock object that just returns values as 'just a stub'. So one way of looking at the difference between mocks and stubs is that with mocks you set and test expectations as part of your test."

Sorry, this is about as clear as mud. "test which methods were called on the mock"? Test them to do what? What else should a mock object return besides values? (via objects). What does it mean to set and test expectations?

Are "mocks" just slightly intelligent stubbs that check incoming params for validity and are slightly intelligent on the data returned?

Ben in DC
PublicMailbox at benslade.com (put 030516 anywhere in the subj to get thru)
"It's the mark of an educated mind to be moved by statistics" Oscar Wilde
[ Parent ]

a mock has expectations (none / 0) (#43)
by bloat on Mon Sep 26, 2005 at 05:11:32 AM EST

A stub doesn't.

With a mock you say something like, 'This class has a method x, and for this test to pass it must be called exactly once with parameters a and b.' If the method is not called, or called with different parameters the test will fail.

With a stub you just say, 'This class has a method x, it's there for the class under test to call or not, I don't care.'

CheersAndrewC.
--
There are no PanAsian supermarkets down in Hell, so you can't buy Golden Boy peanuts there.
[ Parent ]
Yes, it is stupid. (3.00 / 3) (#18)
by Surial on Sat Sep 24, 2005 at 01:35:14 AM EST

To summarize the problem:

The general expectation of unit tests is that they continue to work right; that is, ring the bell when something breaks but play nice when everything still works right.

With 'refactoring' features like ie Eclipse's 'rename method' having a much harder time extending in purely runtime/reflection jokes like passing a method name using a String - writing unit tests like in your example means every little refactor breaks a whole bunch of unit tests, and the bore of fixing them all will either cause you to:

A) Ditch your unit tests, or
B) Leave stupid method names intact because changing them is such a drag, eventhough eclipse and other modern dev environments try to make it a painless process with refactoring wizards.

Beside all this, what the hell is the point of writing a unit test that consists of: This method should call method X exactly once and then get '10' back?

The problem with unit tests is that you can't automatically test everything. For some things unit tests are the clear answer to good programming. For some things, like writing a GUI, unit tests are difficult to get right. Resorting to this kind of fabricated crap just to say you have a unit test is typical by-the-book OO/java developer. Entirely proper, extremely slow, and not very useful at all.

Having said all this, your article requires such a large amount of experience with programming in general and unit tests in particular, that I seriously doubt this article will make it.

NB: reflection = to be avoided as much as possible. 'hard reflection' (where you use reflection eventhough all you're using it for is hardcoded names, such as in your example) is to be avoided absolutely. If there's no way to write a unit test without hard reflection then you ARE better off not writing it or coming up with a different solution altogether. I have and do use reflection, but, oftentimes, when I return to the code at a later date, I manage to get rid of it by doing things a little different.
--
"is a signature" is a signature.

If refactoring breaks your unit tests.. (none / 1) (#38)
by QuantumG on Sun Sep 25, 2005 at 11:33:51 PM EST

then you're not refactoring. Simple as that. Refactoring is defined as a modification of the code that results in no change that could break your unit tests.

Gun fire is the sound of freedom.
[ Parent ]
I disagree... (none / 0) (#44)
by mirleid on Mon Sep 26, 2005 at 06:47:32 AM EST

One of the more common forms of refactoring is to break down a class that has gotten too big/complex in some number of smaller, simpler, more modular ones. Doing that would certainly break unit tests (if for nothing else than that would require you to create more unit tests for the new classes and move tests for methods that are no longer there from the old test class to new ones)...

Chickens don't give milk
[ Parent ]
Having to refactor your unit tests.. (none / 0) (#50)
by QuantumG on Mon Sep 26, 2005 at 07:33:13 PM EST

to make them match the refactoring you've done on the code proper is hardly what I would call "breaking" your unit tests. But if you have to completely rewrite your unit tests for one class, yes, you're refactoring too fast.

Gun fire is the sound of freedom.
[ Parent ]
Did you RTFA? (none / 0) (#56)
by Surial on Fri Sep 30, 2005 at 10:57:16 AM EST

The method name itself is embedded as a loose string into his particular variant of mock-based unit tests. Your average 'rename method' refactoring wizard will not take this into account and hence the unit test will fail eventhough renaming a method always has been and always will be a posterchild 'refactor' job.

--
"is a signature" is a signature.

[ Parent ]
+1FP (2.50 / 2) (#24)
by t1ber on Sat Sep 24, 2005 at 01:23:13 PM EST

+1FP.

I work for a major Java development house in the telecomm industry and they mock everything.  It drives me up a wall since -- in the time it takes me to write mocks for things -- I could probably have written the real object in fairly decent and fucntional code.

And she said...
Durka Durka Mohammed Jihad
Sherpa Sherpa Bak Allah
Hadji girl I can't understand what you're saying.

by-the-book java. (3.00 / 2) (#37)
by Surial on Sun Sep 25, 2005 at 09:09:01 PM EST

Oftentimes in programming language flamewars, the 'community' argument comes up. Or I bring it up. See, PHP isn't a horrible language or anything, but the vast majority of PHP programmers wouldn't know the difference between their arse and their toe when programming, and this reflects directly on the general quality of examples, the product of 'your average PHP programmer' and such things as the security of applications.

PHP programmers, as a rule, tend to throw caution to the wind and make things full of holes. That's by-the-book PHP. Use drastic RAD shortcuts that get the job done but leave stuff full of holes.

Java programmers, as a rule, do the opposite. They tend to, or tend to be instructed to from up-on-high, to follow any number of 'proper programming practices' to absurdity. The recent trend has shifted away from UML and into unit tests, which on the whole is probably an improvement, but it's being taken to similar extremes.

Neither means that either PHP or Java are shit. Neither means someone who has a preference for either language are second-rate programmers. I can come up with a similar 'annoying habit' for just about every programming community. These are just the things that need to be squished if you really want to produce top-notch software products in decent time.

There are situations where unit tests are excellent tools. Such as most of the core libraries that lots of your further codebase will rely on.

Writing a unit test (and the associated crap such as mock objects and GUI playlists) for every little detail is a silly and time wasting practice.

A good programmer knows what programming language to use, and which development concepts to use when writing stuff, depending on the job at hand.

I could preach all day long, but, seeing as you're a dev house slave, you certainly aren't at liberty to change things, are chances are you're aware of all this already.
--
"is a signature" is a signature.

[ Parent ]

-1 (1.00 / 7) (#25)
by Plz No Anonymization on Sat Sep 24, 2005 at 01:42:58 PM EST

Not everyone here reads code you know.

NT: Everyone here should (2.00 / 2) (#26)
by Eight Star on Sat Sep 24, 2005 at 06:01:08 PM EST



[ Parent ]
i need an irc mock object (none / 1) (#28)
by trane on Sat Sep 24, 2005 at 06:38:27 PM EST

to test my bots.

seems like it would be pretty hard though.

Er... Hard? Why? (none / 1) (#30)
by skyknight on Sat Sep 24, 2005 at 09:12:38 PM EST

To test out your bots you presumably just need to feed them a stream of text, ja? What's so hard about that?

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
well i'm using irc bot frameworks. (none / 0) (#51)
by trane on Mon Sep 26, 2005 at 08:54:49 PM EST

i can (and do) have tests that i use on my own components that i use within that framework.

but if i want to test (offline) some kind of operator bot that could, for example, kick/ban spam bots, i would need to mock the entire irc protocol, i think, and that seems like a royal pita, especially because i'm lazy.

[ Parent ]

here (none / 0) (#55)
by army of phred on Fri Sep 30, 2005 at 10:51:39 AM EST

great mock setups for bot testing.

"Republicans are evil." lildebbie
"I have no fucking clue what I'm talking about." motormachinemercenary
"my wife is getting a blowjob" ghostoft1ber
[ Parent ]
yeah i suppose that might work (none / 0) (#57)
by trane on Fri Sep 30, 2005 at 03:26:37 PM EST

then i'd have to have other bots to test the bot i'm working on (to have fully automated tests). but it would be an offline setup.

[ Parent ]
-1 I'm Mocking you. (1.37 / 8) (#29)
by Lemon Juice on Sat Sep 24, 2005 at 07:16:56 PM EST

Mock Mock Mock Mock Mock.

+1, geeky good writing (finally) (1.33 / 3) (#31)
by nostalgiphile on Sun Sep 25, 2005 at 12:19:11 AM EST

Give the geek a cookie and get localroger's diary off the fp b4 I puke, again.

"Depending on your perspective you are an optimist or a pessimist[,] and a hopeless one too." --trhurler
Systems? (none / 1) (#34)
by actmodern on Sun Sep 25, 2005 at 06:09:31 PM EST

What systems do you develop in Java? You must be using the term "system" really loosely here. AFAIK a systems developer implements things like databases, operating systems, file systems, network card drivers.

BTW, the whole unit testing thing you posted was made for crappy programmers who can't write code but have degrees and look good on the company roster when bidding on contracts. That's why they're making you test your code like a child.

--
LilDebbie challenge: produce the water sports scene from bable or stfu. It does not exist.

Right (none / 0) (#35)
by Pseudonym on Sun Sep 25, 2005 at 07:49:10 PM EST

AFAIK a systems developer implements things like databases, operating systems, file systems, network card drivers.

Bingo.

Let's say you're creating a fault-tolerant filesystem. Then you need to be able to test your code in the presence of failure (e.g. network failure or hardware failure). Rather than buy a failing disk for each developer so they can test their code (and hope that each one is failing in the same way), it's much easier to use mock objects.


sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
[ Parent ]
Formal specification (none / 0) (#36)
by Coryoth on Sun Sep 25, 2005 at 09:02:47 PM EST

If fault tolerance is really important then you would probably be well off doing some level of formal specification of your code to cover the corner cases that your testing may not hit.

If you're using Java then JML is a good option. You can then use extended checking with ESC/Java2 and do some theorem proving with KeY. Not to mention that JML itself allows you to automatically generate unit tests based on the specification, as well as providing better documentation at the same time.

Jedidiah.

[ Parent ]

System (none / 0) (#40)
by mirleid on Mon Sep 26, 2005 at 02:25:56 AM EST

From dictionary.com:

sys·tem

    1. A group of interacting, interrelated, or interdependent elements forming a complex whole.
    2. A functionally related group of elements, especially:
        1. The human body regarded as a functional physiological unit.
        2. An organism as a whole, especially with regard to its vital processes or functions.
        3. A group of physiologically or anatomically complementary organs or parts: the nervous system; the skeletal system.
        4. A group of interacting mechanical or electrical components.
        5. A network of structures and channels, as for communication, travel, or distribution.
        6. A network of related computer software, hardware, and data transmission devices.
    3. An organized set of interrelated ideas or principles.
    4. A social, economic, or political organizational form.
    5. A naturally occurring group of objects or phenomena: the solar system.
    6. A set of objects or phenomena grouped together for classification or analysis.
    7. A condition of harmonious, orderly interaction.
    8. An organized and coordinated method; a procedure. See Synonyms at method.
    9. The prevailing social order; the establishment. Used with the: You can't beat the system.
Now that we got that little detail out of the way, and the whole YHBT thing notwithstanding, do you really believe in that tripe that you spewed? I mean, everything has a time and place, and, depending on how long ago one's puberty was, there might be temporary relapses, but that "testing's for wimps" thing is just so last millenium...Unless you have some sort of rationale to offer...

Chickens don't give milk
[ Parent ]
Development (3.00 / 2) (#41)
by zerblat on Mon Sep 26, 2005 at 04:04:35 AM EST

Right, but sometimes generic words have a very specific meaning in a specific field. But I guess pretty much any object with two or more parts is a system, and any human activity aimed at creating or enhancing something could be called "development". So, if I understand you correctly, you spent some time in Indonesia manufacturing safety pins?

[ Parent ]
No, unless Java can be used for that...[nt] (none / 0) (#42)
by mirleid on Mon Sep 26, 2005 at 04:45:12 AM EST



Chickens don't give milk
[ Parent ]
whoosh $ (none / 1) (#54)
by Eustace Cranch on Wed Sep 28, 2005 at 05:27:52 AM EST



[ Parent ]
method names in strings (none / 1) (#45)
by bloat on Mon Sep 26, 2005 at 09:11:43 AM EST

You don't have to put method names in Strings. This is just JMock's way of specifying what gets called. You could equally just implement the interface you're mocking and put the expectations in there. For example (in your test class):


  private class MockDB implements DB {
    public boolean wasCalled;
    public int doQuery(int param) {
      assertEquals(2, param);
      wasCalled = true;
      return 4;
    }
  }

  public void testAClassWhichUsesADB() {
    MockDB db = new MockDB();
    ClassToTest class = new ClassToTest(db);
    class.doSomething();
    assertTrue(db.wasCalled);
  }

This is exactly the same as saying


Mock db = mock(DB.class);
db.expects(once()).method("testDB").with(eq(2)).will(returnValue(4));

Only it takes longer.

I don't see it as hardcoding method names and signatures in tests. They are hardcoded in your interfaces (DB in the example above), naturally your tests must match that.

CheersAndrewC.
--
There are no PanAsian supermarkets down in Hell, so you can't buy Golden Boy peanuts there.

Do not agree that it is the same thing... (none / 0) (#47)
by mirleid on Mon Sep 26, 2005 at 10:15:58 AM EST

Your MockDB class pretty much matches my definition of a stub, not a mock. And the basic difference would be that if somebody changes the DB interface, you'll get a compile time error signalling just that, whereas with the expectation setting code, you'll only find out about it when you run your unit test code.

Chickens don't give milk
[ Parent ]
I don't think its a stub (none / 0) (#49)
by bloat on Mon Sep 26, 2005 at 10:55:52 AM EST

This test will fail if the method doQuery is not called. This makes it more of a mock than a stub, I think.

You're right, of course, this method does have the advantage of compile time checking, whereas with JMock you have to wait until run time, however JMock's way is only two lines long, so...

CheersAndrewC.
--
There are no PanAsian supermarkets down in Hell, so you can't buy Golden Boy peanuts there.
[ Parent ]
EasyMock solves pretty much all of these problems. (none / 1) (#46)
by aehso on Mon Sep 26, 2005 at 09:16:10 AM EST

  • EasyMock (http://www.easymock.org/) does not suffer from a lot of the problem you mention about encoding method/types/param names in test code to prime the Mock object. The Easymock framework provides the mock implementation object by dynamically compiling a mock impl of the same target interface/class. Your code just primes the object with return values or exceptions to throw. This allows you to use refactoring tools like those provided by Eclipse - the tests will follow the refactoring and/or the compiler will tell you that the tests don't build.
  • method call checking is vital to ensure that the code you are testing followed the expected execution path, particularuly when looping/recursion is being used. Simply checking that an object has the correct state at the end of a test is not sufficient.
  • ksandstr, you've obviously had some bad experiences working with Java in the past but your comments are not a mature reflection on Java programming in general. There are monkeys writing code in every language and language features like reflection, dynamic proxies, inner and inline classes shouldn't, but are, being misused by them in Java (and C#). Blame the monkeys, not the typewriters.


Not so sure... (none / 0) (#48)
by mirleid on Mon Sep 26, 2005 at 10:33:08 AM EST

...that method call checking is vital. You have a point in terms of the expected execution path (all the more so if you are doing some interesting like generating mock-based unit tests from UML sequence diagrams), but not too much thought has been put into figuring out the impacts of the approach in a relatively large project where you have a lot of people doing development (and, as such, with a high degree of change happening in relatively short periods of time).

So, I am not saying that execution path testing is bad, I am just saying that doing it the way that is proposed by the writers of the paper that I was comenting on seems (at least to me) to have a number of large drawbacks that they have not addressed...

Chickens don't give milk
[ Parent ]
What's wrong with a little design? (none / 1) (#52)
by DanielMarkham on Tue Sep 27, 2005 at 04:10:53 AM EST

To me this just seems to be one of those "I have a hammer, therefore all problems must be nails." mentalities.
A little design, perhaps, before you code, might put some structure in place for your unit tests. Color me crazy, but we already know how to grow the simplest solution to complex problems -- it's called OOA/D. Using mock objects as a vehicle of discovery is ass-backwards. Any large types you could possibly discover you should have found the previous week during the walk-through. And why the heck would I want to start every solution with coding one object? That's like building a car by buying a wheel from the junkyard and trying to figure out the car by what connects to the wheel.

Nothing's wrong with a little design... (none / 0) (#53)
by mirleid on Tue Sep 27, 2005 at 11:22:36 AM EST

...it's just that the requirements discovery/refinement process is supposed to be integrated with development when you do Test Driven Development...

Not saying that it is good or bad or even applicable to all possible sets of circumstances...

Chickens don't give milk
[ Parent ]
To mock or not to mock | 58 comments (50 topical, 8 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!