Review My Unit Test / MockBox

Hello Guys,

I’m very new to unit testing and mocking. I wanted to run my code past you and get some feedback, on what I could do better, what I’m doing horrible wrong and so forth.

I’m going to use this simple security service use case: http://pastebin.com/NSk7aWz1

I’ve got the following test written for it: http://pastebin.com/Gv4HehkL

I really appreciate anyone taking the time to look at those for me.

The tests appear to work just fine, there may just be better/cleaner ways of doing things.

Thanks,

Robert

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

http://www.andyscott.id.au/

HI Andrew,

Thanks for the feedback, I really appreciate it.

I understand the TDD concept, and it makes a great deal of sense. I just wanted to start by coding a couple of tests for service I know work, to get a handle on how they should be written!

So, what you're saying is that you'd combine my three different login tests into a single test method? with multiple assertions at different points?

Thanks again bud,

Robert

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.

Regards,

Andrew Scott

http://www.andyscott.id.au/

Thanks Andrew,

I really appreciate the information, it's great to see how other people are doing things.

I shall write some 'group' tests in a single method and see how intuitive it feels, I'm sure I'll soon see if it works for me or not.

Thanks again,

Robert