The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

private methods are indirectly tested via the public methods that use them, provided you haven't partiallyMocked them away.

Generally speaking, this is what you want -- you know the private method work because the public interface works. If you change the innards, the existing tests should still catch any outwardly visible change of behavoir.

Perhaps unit testing just isn't as good as I'd like to think it is then. I have some private methods that do some complicated stuff each. The public methods use combinations of these to do the bigger jobs for which the class is intended.

I want to test that the smaller jobs are getting done correctly. Do you suggest I go back to echoing out variables and stuff again? I'm not actually trying to be obtuse, but I was under the impression unit testing got rid of a lot of that stuff.

Perhaps unit testing just isn't as good as I'd like to think it is then. I have some private methods that do some complicated stuff each. The public methods use combinations of these to do the bigger jobs for which the class is intended.

I want to test that the smaller jobs are getting done correctly. Do you suggest I go back to echoing out variables and stuff again? I'm not actually trying to be obtuse, but I was under the impression unit testing got rid of a lot of that stuff.

Sounds like you may have just found a bigger problem which means testing is doing its job. Would it make any sense to put these methods in their own class?

Perhaps unit testing just isn't as good as I'd like to think it is then. I have some private methods that do some complicated stuff each. The public methods use combinations of these to do the bigger jobs for which the class is intended.

I want to test that the smaller jobs are getting done correctly. Do you suggest I go back to echoing out variables and stuff again? I'm not actually trying to be obtuse, but I was under the impression unit testing got rid of a lot of that stuff.

Yeah I agree with Buddha, if the private methods are that complicated, then I'ld look at doing an "Extract Class" refactoring to pull the out ot a new class that the existing class uses.

I'm not sure if there is any way to mock the public properties -- is there a good reason for them being public? Why not create getters (and setters as required), moving the public parameters to private and the setting the return value for the getters, etc

"Pointless" getter/setters have long been one of my chief complaints of OOP; however now that I'm doing TDD; I'm finding that I seldom need them. When I do its appropriate and I don't mind writing them.

You guys may be right about the complexity of this class, I'll have a think about that.

You are about to hit a classic chicken and egg situation. You want unit tests to safely refactor the class, but the class can't be tested until it's refactored .

The way out of this trap is to do a single integration test, or a heavily mocked unit test, that covers a lot of code. That way at least you know when it breaks. You won't know where, you don't yet have the fine grain testing, but at least it gives you a safety net to refactor.

Regarding member variables and private methods, there is not much I can do. However, one of the positive effects of mock objects is that they help you design the code. If it's hard to test then it's probably inflexible in other ways.

No, you don't. You wan't to test that when someone (another class) calls your classes' public methods, they behave correctly. Your tests couldn't care less about the private methods -- but if they don't work correctly, neither your public methods will, which.

In other words, always implement to the interface: first determine the public methods for a class, and then implement them. It's alright if you move some of the code into helper private methods, but they are just Toby Zieglers to your president Bartlets.

Perhaps unit testing just isn't as good as I'd like to think it is then. I have some private methods that do some complicated stuff each. The public methods use combinations of these to do the bigger jobs for which the class is intended.

I want to test that the smaller jobs are getting done correctly. Do you suggest I go back to echoing out variables and stuff again? I'm not actually trying to be obtuse, but I was under the impression unit testing got rid of a lot of that stuff.

Failure messages will often tell you what you need to know but you do need the odd $this->dump or print_r when something isn't working in a test case. Because tests are quite focussed, it's nothing like as bad as wading through entire scripts and because tests are repeatable at the click of a button, once you've got the test passing you'll never have to do it again.

Depending on just how complicated this stuff is, you might have found some different responsibilities which could be refactored into classes of their own (as has been mentioned). I find testing is a good influence on the code in various ways - not least that smaller more tightly focussed classes are easier to test and so that's what you tend to write. It could be that this is part of the problem you're having.

The point about mocks is that they're a design tool. When you define a mock object, you don't need to consider how it will be implemented. All you want to do is to describe how it should interact with the primary class: what methods are called, with what arguments, and what values are returned. The mock objects left behind by the primary class's test are the next step in the design - some pencil sketches to be coloured in with a concrete implementation. Are you trying to test the mock objects too soon? Wait until you come to write implementations for these.

Incidentally, wouldn't it be nice if there was some way to code generate tests for mock objects based on the expectations set in other test cases...

Hi...
You are about to hit a classic chicken and egg situation. You want unit tests to safely refactor the class, but the class can't be tested until it's refactored .

*sniffles
this is sadly where I'm at now trying to maintain a mess of code that I inherited. I'm going to attempt to at least get all the functionality under a webtest case so I can start refactoring into more testible code (p.s. thanks for adding that lovely feature).

I have been wanting to look at this for some time, but I have been so busy with the web browser portion that now is really the first chance I have had to refactor the mock objects. Once the internals have been sorted. I can evaluate the options.

I'd realy like to have a method of syncing the mocks with their undelying objects.

I remember asking the original question and being perplexed about the answer. But then I realized how primitive PHP still is. You can freely set and get any variable that hasn't been declared. This works:

PHP Code:

class Foo {
private $bar;
}

$foo = new Foo;
$foo->baz = 42;
echo $foo->baz."\n";

But this fails:

PHP Code:

$foo->bar = 43;

I guess the only way to control all instance variable accesses is to use __get() and __set().