Review My Unit Test / MockBox
Rawlins
Andrew Scott
Looks very good to me, however I only have one piece of advice.
Try to get into the habit of writing your tests first, and although this is not a hard fast rule. But it is something that I tend to do, and I find it means I can get better code coverage because of it.
I tend to keep everything related to a method / API in one test method, this is because in the one test you can check for a successful login and a successful logout, as with your example. This might not become apparent if you don’t use the Eclipse mxUnit views, where you can run one test only, while developing and if you change one thing in trying to fix your first method test, you may break the other and you are potentially wasting time. Going back and forth on these two tests all the time.
Being able to just run the one test while developing, also saves a lot more time as well. Not only because you are only running the one test, but you are not waiting 10-30mins later for the entire test suite to run. But the bonus of keeping all the logic in one test, for success and failure means you aren’t wasting more time by going and running test when you don’t need too.
Otherwise, it is very clean and right on the money.
Regards,
Andrew Scott
--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org
Robert Rawlins
Andrew Scott
Yea and good job on what you have learnt.
And yes I do mean that, I also use the message option on the asserts as in the following example.
rc.email = 'isthisanemail@.com';
errors = blogService.addComment(instance.event);
assertTrue(arrayLen(errors), 'Did not return an array of errors for incorrect email');
assertEquals('Please enter a valid email address', errors[1].getMessage(), 'When checking to see if the email was valid it went wrong.' );
This is just one of many, and is example of multiple things that need to be checked. This is adding a comment to a blog post, and checks that the email is valid. Which first’s checks to see if an array of errors are returned, and then checks that the message returned is indeed what we expect.
Same as what you did with your example, but I also have all other known inputs and outputs catered for in the one test here.
I know that many people will argue the fact that you don’t need to do it the way I do it, but I wanted to suggest it and give you an oppurtunity to make up what works for you. I have the ability to run 3 sets of tests in development, one with just running the one test I am working on and if I am satisified that this works. Then I run the entire suite in the view to double check it all passes, and the last but not least is when building the staging server, is when it is run again just to make sure the build is stable.
But if you imagine in a life cycle how many times you run your tests while you code, and then having to wait for your suite to end. You can see how much time is wasted very quickly, and which is why I have chosen to implment it this way. Take a great deal of patience and persistence, but it is worth it in the end.