Junilu Lacar wrote:Trying to decipher your test code to understand its intent, I see the when part exercising the method under test, getImages(). The expectation is that you'll get 3 items. In the given section, you set up four files, three of which are similar and one different. I assume the three items you expect to get from the method under test are the similarly configured ones in the given section, right?
This is not easy to discern and suggests that your API can be made more intuitive so that the test code can clearly express what the intent is.
Tim Cooke wrote:Even just removing the interaction assertion makes it work ok for me. Makes no sense.
Junilu Lacar wrote:I've only been able to make Tim's test work if I change Mock() to Stub() and remove the interaction check. But that kind of changes the test.
Asif Haciyev wrote:Also, when I change this
the test passed.
Junilu Lacar wrote:I put in a bunch of checks but the baffling thing is that somehow if you use Mock(), the stubbing gets clobbered when you make the critical call to getAllMembers() -- it seems as if the mocked findAll() method exhibits default behavior of returning null all of a sudden even though you still have the same mock object (I verified this using hashCode())
Junilu Lacar wrote:My understanding from what I read in the documentation is that the "1 *" causes it to be interpreted as an expected interaction vs. just a plain old method call.
Junilu Lacar wrote:Did you double-check that memberRepository is not null?
Junilu Lacar wrote:
What does the service constructor look like? Just want to make sure all the basic assumptions are correct.
With that code, we're assuming that the constructor properly sets a memberRepository field.
If that checks out, I would try moving those two lines to given block to see if that makes a difference. I know the setup() block should work but again, I would just want to eliminate these as possible causes.
Stephan van Hulst wrote:
Asif Haciyev wrote:.../index.html file contains this
That's just the HTML to show the test report. If you open it in a browser it should show you the actual test report.
Junilu Lacar wrote:In your code, what does the data being piped get assigned to? Does it take everything in the right hand side and put it into the members array/collection? Have you tried debugging to check that members is not null?
Stephan van Hulst wrote:Is there no stack trace at /ms-team/build/reports/tests/test/index.html?
Tim Cooke wrote:Without running your code, which I can't do right now, I'd say it's most likely because you have not instructed the mock memberRepository object to return anything when findAll() method is called. I recommend you double check the syntax for doing that with Spock.
Tim Cooke wrote:
This looks highly suspicious to me, especially the MemberMapper line. It looks like you're defining Spock like instructions on an object that is not a Spock mock object so mockMembers is unlikely to be in the state you expect.
Tim Cooke wrote:Alright, entityToDtoList(null) returns null. Now let's look at your code to see if that behaviour is handled appropriately: