I have 2 JUnit tests out of 7 that are failing on me. I can't seem to pinpoint how to fix the code or rework the tests so they'll pass. I'm not experiencing any errors with the code the unit tests are testing.
How are you debugging those methods? What is going wrong?
Why do your methods return aBoolean? Most of the second half of the seond method is redundant, because you can write:-Your indentation is inconsistent; you can hide all sorts of errors behind incorrect indentation.
Why are you sometimes using UPPER_CaseMostly and sometimes MixedCase for class names? Why is the if in line 4 so long? There is something weird about seeing a condition with so many dots operators in.
posted 9 months ago
testRegister returns a Boolean to indicate to the servlet if the user was successfully registered, otherwise it serves a 500 status code.
That code was redundant, thank you.
ERS is upper case because it's an acronym for Employee Reimbursement System.
The dot operators in the conditional were necessary because that method returns an Optional so I can forego returning a null. It's just doing null checking on the username to see if it's available.
As for issues I'm having with the tests, in testRegister the isUserValid method is is throwing an InvalidRequestException even though I have mocking code that, I believe should handle the isUserValid method.
I've tried this 2 ways, with a mocked ERS_Users variable and with an ERS_Users variable that's actually instantiated. It's line 3 in testRegister that throws the exception:
Andrew Spiteri wrote:how to fix the code or rework the tests so they'll pass.
"Reworking" the tests so they'll pass is the wrong goal. Your test should clearly express a "story" of what should or shouldn't happen when behavior in your class under test is invoked. As it is now, that story is not very clear. I spent a good 10 minutes trying to understand what those tests are trying to do/say and I couldn't make heads or tails of it. So, the first thing I would do is make the test code clearly express its intent.
The mock objects and static methods seem wound around the class under test very tightly. There's too much coupling in this code. This is another thing that makes this test and the code it's testing difficult to understand.
If I work backwards from the assertion, the updateStatus(csi) is expected to return true. None of the lines before the call to updateStatus(csi) gives me any idea of what exactly this csi variable is though. There's also no clear indication where the rr object comes from but since it's used with when(), then I'd assume it's supposed to be a mock object. But then in the production code, the return value comes from a call to rr.updateReimbStatus(ers). This is very confusing and leads me to think that you're just as confused by this code. I can't tell which is the real code that's being tested and what are mock objects.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck