I have a model with a method named foo( required myArg )
In a Unit test I want to write one test on that method that passes and then another to make sure it throws an error without the required argument.
Is it best to mock this method for the test that checks for an error and use the throwException property to fail it or wrap my code in the model in a try/catch statement and throw a message back there and just use the toThrow() matcher in my expectation? Or maybe something entirely different?
I’m thinking either one might be ok to do, but would like to make sure I’m writing this test correctly.
Any opinions would be greatly appreciated.
Thanks,
Ben
Ben,
I am all for testing, you know that. However, I don’t know what value you will be getting by testing that required arguments are throwing an exception. I think that you have to be pragmatic when it comes to testing. If not, it will get boring and tedious very very quickly.
I would suggest things like those be done more in integration testing, so you can evaluate that a given feature does do error trapping when having missing arguments.
However, if you want to go for it. just use the toThrow() expectation and don’t call it with an argument.

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
ContentBox Platform: http://www.gocontentbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano | twitter.com/gocontentbox
Thanks for your insights on this Luis. I knew that the only way this argument may not have been passed is when the event is called so I guess it does make more sense to catch this in the integration test, which I was going to add anyway, so I see your point in it kind of being redundant to then write a test for the Model as well.
Thank you again,
Ben
No problem Ben.
The BDD approach has definitely inspired to be more creative with the tests rather than vanilla unit tests, which can lead you to hours of boringness and un-productivity. Sometimes, that’s where developers give up on testing, because it becomes so redundant.
I find, with the BDD and integration approaches, you have more purpose in mind of actually finding out if your “feature” actually works or how it responds to bogus input or situations.

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
ContentBox Platform: http://www.gocontentbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano | twitter.com/gocontentbox