Hi there,
I have a dilemma with this whole thing.
Take a logout method inside a loginService for example....
I could mock up a "login" object inside a mock "Sessionstorage" object
and inject that into my service.
I could then ask the logout() to check that the login object exists in
the storage, delete it if it does and then return something (boolean)
maybe to say the user has been logged out.
That's fine as MockBox can show me in my test results that logout
accessed my mock object and tried delete something.
The issue is though I'm not actually testing this against
sessionStorage so if for example they change the way that plugin works
in the future & we want to test against that my mocks aren't going to
show me any problems.
So the question is - when do you mock and when do you use th real
thing?
Do you write two sets of tests ... one to test the logout() behaviour
is right through mocking & one that checks its working with ColdBox?
Or is mocking in this situation not the right thing to do?
Cheers,
James
Wow!
Excellent question James. Just to be clear, the testing of the session storage is for what?
I mean, the expectations of the session storage is just like any other scope, put things in, take things out, so I would just rely in the idea that the expectations for such object will be true.
I do however, would recommend integration tests via event handler testing. This way, you are doing a top-down test of the entire application process, which is more real than simple unit testing with mocking.
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Thanks again for the reply Luis 
The login object is something that's created on login to our
application. It's stored in the sessionstorage throughout so it made
sense to have the logout() do the checks in there and clear out
anything it needs from the backend.
Originally I did just have it returning void as I had the same idea as
you in that it would always return true. I kind of had a change of
heart after that and thought that by giving a true / false reply to
whatever is calling logout() extra checks could then be made.
Integration test - Funny you say as I actually visited that before
hitting the mocking, and I'm off to revisit now ;-).
My only issue with this approach is everything "that gets in the way"
when all I want to do is test that single method. What I liked about
the mocking was I didn't have to worry about the dependency setup or
framework.. It might suit this situation because right now the event
I'm doing looks like this ......
<cffunction name="doLogout" returnType="void" output=false hint="I
handle the processing of a logging out and sending the user to a
display event">
<cfargument name="event" required=true />
<cfscript>
// Logout and redirect to the diplay event for all things logging
out
getPlugin('ioc').getBean('LoginService').logout();
setNextEvent('login.logout');
</cfscript>
</cffunction>
... as simple as it gets so I guess in this situation it's not bad to
do integration. I've got others more complex though, using more than
one services and several checks going on, so in that case I don't know
if I'd be better to test each one individual and then look to maybe do
a single integration test for the whole thing.
Too many choices :-).
Thanks for the pointers though like I say I'll have a play with
integration and see how I get on.
Cheers,
James
No problem James.
Integration is the full test for everything, so if you are just building your services and domain model, this might not go into effect as none of the other parts are yet built.
So I would concentrate on the unit and mock tests to finalize the services and domain model. Once those satisfy your expectations, then once the handlers and app are being built I would throw in the integration tests to validate your work. This is my typical flow.
Domain development alongside unit/mocking
Handler development with integration testing
View development (then I can add selenium or other type of UI validation tests if necessary, or even use integration testing by leveraging the Renderer plugin and validating HTML there).
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com