Warning: Cannot modify header information - headers already sent by (output started at /customers/4/c/9/iconara.net/httpd.www/blog/wp-content/advanced-cache.php:1) in /customers/4/c/9/iconara.net/httpd.www/blog/wp-includes/feed-rss2-comments.php on line 8
Yes, if you test private methods you do something that “private” is meant to avoid: place dependencies on code that is internal and subject to change. So don’t. It should suffice to test the public interface of your unit, i.e. class. I agree that sometimes you would like to write a test for a subunit, like a private or protected method, because it is complex and you would like to make sure that it really does what it’s supposed to do, but don’t. Refactor your code instead. If that method is so complex or critical and you really need to test it separately, perhaps it would be better to extract it into it’s own class (which a suitably abstract interface). In Refactoring Fowler mentions the situation and if I remember correctly the advice is that either it’s public and you test it, or you refactor until you can test it (but still maintain the level of information hiding you should have).
Some testing isn’t practical to do automatically, you will always have to do visual tests — for example to make sure that, say, a button not only is disabled, but looks disabled. So, consider the situation when you have a presentation model with a property that determines if a button is enabled, and a method that is called when someone clicks the button. You also have a view with the button in question, and it binds the
enabled property on the button to the
buttonIsEnabled property to the presentation model, and sets up the event handler to call the method when the button is clicked. What part of this setup should you aim to test in automated tests?
The state of the presentation model, e.g. manipulating it in such a way that the
buttonIsEnabled property should be set to false and checking if that is the case, and also running the related method to see what happens (perhaps it should silently ignore calls when the button is disabled, or throw an exception).
That the view responds to changes in the presentation model, e.g. when the
buttonIsEnabled property is false the
enabled property on the button is false, etc.
That the button is greyed out when it is disabled and that it is positioned to the right of an input field.
I’d say the yes, absolutely, to the first point. I’m very sceptical to the second, it could be done, but I don’t see the point. Just because you can doesn’t mean you should test everything, some things are too simple to test, like getters and setters (that don’t have any complex boundary checking, of course), and this is more or less the same, there’s too little to gain from writing the test.
To the third point I’d say you’re nuts if you think it would be a good test to write, because this is the kind of thing you can only test visually. Autmatic testing of things like layout, positioning, colour, etc. can’t give you the level of confidence that you need, because what you measure isn’t relevant. The requirements of layout don’t call for the kinds of things you can spell out in an automated test.
Even though you can write many kinds of tests that test your application at many levels, there are limits to what is practical and what you would gain from testing it automatically. You don’t test getters and setters, because the time writing the test doesn’t pay itself in terms of your productivity, you can be pretty sure that the setter will work correctly because it is only one line. The same goes for bindings (although there are exceptions) and some other things that are related to the layout and updating of a view.
From the description in the comment above this I’m not sure you’re talking about “view” as in the “V” in “MVC” or “view” as in a view class. Maybe I’m just misinterpreting, and if I am just ignore this. Each view, as in view class (MXML file essentially), should have its own presentation model companion, and if either the view or the presentation model starts getting complex, you refactor and create a number of subviews, all with their own presentation model. The tricky bit with Presentation Model (the pattern) is to get the presentation model objects into the right views the right way. There are different ways of doing this, and it can depend on the application framework you use.
It was something else that you said, which I can’t seem to find now, that got me thinking about the PAC meta pattern, Presentation-Abstraction-Control. Basically you have a model, a view and a controller in each component, sort of like OpenFlux. It definitely has its uses, especially in component development, where you otherwise easily end up with one fat class that does a little too much. When it comes to crafting views in applications I think that Presentation Model (and the Model-View-Presenter with Application Controller meta pattern) is more suitable.
There’s a good article on different application architecture meta patterns here: http://ctrl-shift-b.blogspot.com/2007/08/interactive-application-architecture.html]]>
Considering a component to be a unit itself, it’s own model and logic should be quite easy to test, regardless of any integration. Please do correct me if I got you all wrong.
System integration however will probably always be an issue, as is diligently mentioned in the Google Testing Blog:
“Of course, all the complex issues of integration and system testing remain. Good unit testing gives me a good head start for integration, but I might still be in for unpleasant surprises there.”]]>