I'm entirely new to Grails and it's testing functions since I started my current job approx 4 months ago. The person who trained me on testing left our group several weeks ago, and now I'm on my own for testing. What I've slowing been discovering is that the way I was trained on how to do Grails integration testing is almost entirely different from the way(s) that I've seen people do it on the forums and support groups. I could really use some guidance on which way is right/best. I'm currently working in Grails 2.4.0, btw.
Here is a sample mockup of an integration test in the style that I was trained on. Is this the right or even the best way that I should be doing it?
#Test
void "test a method in a controller"() {
def fc = new FooController() // 1. Create controller
fc.springSecurityService = [principal: [username: 'somebody']] // 2. Setup Inputs
fc.params.id = '1122'
fc.create() // 3. Call the method being tested
assertEquals "User Not Found", fc.flash.errorMessage // 4. Make assertions on what was supposed to happen
assertEquals "/", fc.response.redirectUrl
}
Since Grails 2.4.0 is used, you can leverage the benefit of using spock framework by default.
Here is sample unit test case which you can model after to write Integration specs.
Note:
Integration specs goes to test/integration
should inherit IntegrationSpec.
Mocking is not needed. #TestFor is not used as compared to unit spec.
DI can be used to full extent. def myService at class level will inject the service in
spec.
Mocking not required for domain entities.
Above spec should look like:
import grails.test.spock.IntegrationSpec
class FooControllerSpec extends IntegrationSpec {
void "test a method in a controller"() {
given: 'Foo Controller'
def fc = new FooController()
and: 'with authorized user'
fc.springSecurityService = [principal: [username: 'somebody']]
and: 'with request parameter set'
fc.params.id = '1122'
when: 'create is called'
fc.create()
then: 'check redirect url and error message'
fc.flash.errorMessage == "User Not Found"
fc.response.redirectUrl == "/"
}
}
Related
I am working with
STS
Gradle
Spock Core
Spock Reports
Spock Spring
Spring MVC Testing
I have the following test code:
#WebAppConfiguration
#ContextConfiguration(classes=[RootApplicationContextConfig.class,ServletApplicationContextConfig.class])
#SuppressWarnings("deprecation")
class PersonaXmlFindOneControllerTest extends Specification {
#Autowired
private WebApplicationContext webApplicationContext;
private MockMvc mockMvc;
private PersonaXmlFindOneController personaXmlFindOneController
def setup(){
mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext).build();
personaXmlFindOneController = webApplicationContext.getBean(PersonaXmlFindOneController.class);
println personaXmlFindOneController.toString()
}
def "findOneRequestParamById deberia ser llamado"(){
String url = null
ResultActions resultActions = null
given: "The URL being used "
url = "some url to test"
when: "When the URL is being calling with a GET"
resultActions = mockMvc.perform(get(url, PersonaControllerSupport.ID)).andDo(print())
then: "...."
resultActions.andExpect(status().isOk())
.andExpect(content().contentType(MediaType.APPLICATION_XML))
.andExpect(xpath("persona").exists())
.andExpect(xpath("persona").nodeCount(1))
….
//then:
//1 * personaXmlFindOneController.findOneRequestParamById(_ as String)
}
The code works fine. It pass.
Furthemore: through Gradle Test Report thanks to andDo(print()) I can confirm that personaXmlFindOneController.findOneRequestParamById has been called.
It means
Handler:
Type = com.manuel.jordan.controller.xml.PersonaXmlFindOneController
Method = public com.manuel.jordan.domain.xml.PersonaXml com.manuel.jordan.controller.xml.PersonaXmlFindOneController.findOneRequestParamById(java.lang.String)
Now If enable
//then:
//1 * personaXmlFindOneController.findOneRequestParamById(_ as String)
The code fails,
Too few invocations for:
1 * personaXmlFindOneController.findOneRequestParamById(_ as String) (0 invocations)
Unmatched invocations (ordered by similarity):
None
Observe that in the setup method, it has been retrieved through
personaXmlFindOneController = webApplicationContext.getBean(PersonaXmlFindOneController.class);
Therefore, what is missing or what is wrong?
You are mixing two different mocking mechanisms.
There is the Spring one (MockMVC) and the Spock one.
Spock can only verify mocks created by itself (.i.e those created with the Spock Mock() method). You don't create any Spock mocks in your code and therefore Spock mocking will not work.
See the official documentation of Spock for the full mocking guide to understand how you can create mocks with Spock only.
In your particular example your original code is correct and it should stay that way. You don't always have to use the Spock mocking mechanism. Having a Spock test that uses only Spring testing facilities is perfectly fine.
I've got a question about how to share rspec-mocks' double between examples. I'm writing a new rails app with rspec-mocks 3.1.3. I'm used to using the old (< 2.14 and and trying to update my knowledge if current rspec usage.
I have a model method:
def self.from_strava(activity_id, race_id, user)
#client ||= Strava::Api::V3::Client.new(access_token: 'abc123')
activity = #client.retrieve_an_activity(activity_id)
result_details = {race_id: race_id, user: user}
result_details[:duration] = activity['moving_time']
result_details[:date] = Date.parse(activity['start_date'])
result_details[:comment] = activity['description']
result_details[:strava_url] = "http://www.strava.com/activities/#{activity_id}"
Result.create!(result_details)
end
And here is the spec:
describe ".from_strava" do
let(:user) { FactoryGirl.build(:user) }
let(:client) { double(:client) }
let(:json_response) { JSON.parse(File.read('spec/support/strava_response.json')) }
before(:each) do
allow(Strava::Api::V3::Client).to receive(:new) { client }
allow(client).to receive(:retrieve_an_activity) { json_response }
allow(Result).to receive(:create!)
end
it "sets the duration" do
expect(Result).to receive(:create!).with(hash_including(duration: 3635))
Result.from_strava('123', 456, user)
end
it "sets the date" do
expect(Result).to receive(:create!).with(hash_including(date: Date.parse("2014-11-14")))
Result.from_strava('123', 456, user)
end
end
When I run a single test on it's own it's fine, but when I run the whole describe ".from_strava" block it fails with the message
Double :client was originally created in one example but has leaked into another example and can no longer be used. rspec-mocks' doubles are designed to only last for one example, and you need to create a new one in each example you wish to use it for.
I understand what it's saying, but surely this is an appropriate use of a double being used in 2 examples. After all, the client double isn't important to the example, it's just a way for me to load the canned response. I guess I could use WebMock but that seems very low-level and doesn't translate well to the actual code written. We should only be asserting one thing per example after all.
I had thought about replacing the client double with a call to
allow(Strava::Api::V3::Client).to receive_message_chain(:new, :retrieve_an_activity) { json_response }
but that doesn't seem to be the right approach either, given that the documentation states that receive_message_chain should be a code smell.
So if I shouldn't use receive_message_chain, shared client double and also follow the standard DRY principle then how should I fix this?
I would love some feedback on this.
Thanks,
Dave
Caching clients for external components can often be really desired (keeping alive connections/any SSL setup that you might need, etc.) and removing that for the sake of fixing an issue with tests is not a desirable solution.
In order to fix your test (without refactoring your code), you can do the following to clear the instance variable after each of your tests:
after { Result.instance_variable_set("#client", nil) }
While admittedly, this is not the cleanest solution, it seems to be the simplest and achieves both, lets you have a clear setup with no state shared in between tests, and keep your client cached in "normal" operation mode.
surely this is an appropriate use of a double being used in 2 examples.
No, it's not. :) You're trying to use a class variable; do not do that because the variable doesn't span examples. The solution is to set the client each time i.e. in each example.
Bad:
#client ||= Strava::Api::V3::Client.new(access_token: 'abc123')
Good:
#client = Strava::Api::V3::Client.new(access_token: 'abc123')
I had the same use case in an app of mine, and we solved it by extracting the cacheing into a private method and then stubbing that method to return the double (instead of stubbing the new method directly).
For example, in the class under test:
def self.from_strava(activity_id, race_id, user)
activity = strava_client.retrieve_an_activity(activity_id)
...
end
private
def self.strava_client
#client ||= Strava::Api::V3::Client.new(access_token: 'abc123')
end
And in the spec:
let(:client) { double(:client) }
before { allow(described_class).to receive(:strava_client).and_return(client) }
...
TLDR: Add after { order.vendor_service = nil } to balance the before block. Or read on...
I ran into this, and it was not obvious where it was coming from. In order_spec.rb model tests, I had this:
describe 'order history' do
before do
service = double('VendorAPI')
allow(service).to receive(:order_count).and_return(5)
order.vendor_service = service
end
# tests here ..
end
And in my Order model:
def too_many_orders?
##vendor_service ||= VendorAPI.new(key: 'abc', account: '123')
return ##vendor_service.order_count > 10
end
This worked fine when I only ran rspec on order_spec.rb
I was mocking something completely different in order_controller_spec.rb a little differently, using allow_any_instance_of() instead of double and allow:
allow_any_instance_of(Order).to receive(:too_many_orders?).and_return(true)
This, too, tested out fine.
The confounding trouble is that when I ran the full suite of tests, I got the OP's error on the controller mock -- the one using allow_any_instance. This was very hard to track down, as the problem (or at least my solution) lay in the model tests where I use double/allow.
To fix this, I added an after block clearing the class variable ##vendor_service, balancing the before block's action:
describe 'order history' do
before do
service = double('VendorAPI')
allow(service).to receive(:order_count).and_return(5)
order.vendor_service = service
end
after do
order.vendor_service = nil
end
# tests here ..
end
This forced the ||= VendorAPI.new() to use the real new function in later unrelated tests, not the mock object.
I have a service method that locks a database row.
public String getNextPath() {
PathSeed.withTransaction { txn ->
def seed = PathSeed.lock(1)
def seedValue = seed.seed
seed.seed++
seed.save()
}
}
This is how my spock test looks like:
void "getNextPath should return a String"() {
when:
def path = pathGeneratorService.getNextPath()
then:
path instanceof String
}
It's just a simple initial test. However I get this error when I run the test:
java.lang.UnsupportedOperationException: Datastore [org.grails.datastore.mapping.simple.SimpleMapSession] does not support locking.
at org.grails.datastore.mapping.core.AbstractSession.lock(AbstractSession.java:603)
at org.grails.datastore.gorm.GormStaticApi.lock_closure14(GormStaticApi.groovy:343)
at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:302)
at org.grails.datastore.gorm.AbstractDatastoreApi.execute(AbstractDatastoreApi.groovy:37)
at org.grails.datastore.gorm.GormStaticApi.lock(GormStaticApi.groovy:342)
at com.synacy.PathGeneratorService.getNextPath_closure1(PathGeneratorService.groovy:10)
at org.grails.datastore.gorm.GormStaticApi.withTransaction(GormStaticApi.groovy:712)
at com.synacy.PathGeneratorService$$EOapl2Cm.getNextPath(PathGeneratorService.groovy:9)
at com.synacy.PathGeneratorServiceSpec.getNextPath should return a String(PathGeneratorServiceSpec.groovy:17)
Does anyone have any idea what this is?
The simple GORM implementation for Unit tests does not support some features, such as locking. Moving your test to an integration test will use the full implementation of GORM instead of the simple implementation used by unit tests.
Typically when you find yourself using anything more than the very basic features of GORM you will need to use integration tests.
Updated 10/06/2014
In more recent versions of Grails and GORM there is now the HibernateTestMixin which allows you to test/use such features in Unit tests. Further information can be found in the documentation.
As a workaround, I was able to get it working by using Groovy metaprogramming. Applied to your example:
def setup() {
// Current spec does not test the locking feature,
// so for this test have lock call the get method
// instead.
PathSeed.metaClass.static.lock = PathSeed.&get
}
I'm writing the Integration test for a Quartz Job in a grails application.
I've the Job in grails-app/jobs folder, and if I start the application it works. The problem is that I want to get it in an integration test, but the autowire won't work. The test is like:
class MyJobTest{
MyJob myJob
def setUp(){
assert myJob != null
}
def testExecute(){
//test logic
}
}
but it fails because myJob is null...some help?
Quartz Jobs are not autowired like services are under the test environment. The documentation for the Quartz job also explicitly states that by default it will not execute on schedule under the test environment (you could change that if you want to but I wouldn't). I would just instantiate myJob = new MyJob() in your setUp and call the execute() method to test it. If you're trying to test the triggers you may want to find a way to look at what is inside the triggers {} maybe inspecting the metaClass?
EDIT IN RESPONSE TO COMMENT:
I've never gotten the services out of the application context so that might work. The way I would probably test it is as follows:
Assuming your class looks something like this:
class MyJob {
def myServiceA
def myServiceB
def execute() {
if(myJobLogicToDetermineWhatToDo) {
myServiceA.doStuff(parameter)
} else {
myServiceB.doStuff(parameter)
}
}
}
What you're really wanting to test here is the myJobLogicToDetermineWhatToDo. I would assume that you have (or can easily write) integration and/or unit tests against your services myServiceA and myServiceB to ensure that they are working correctly. I would then write unit tests to test the logic/wiring of your Job to the appropriate service.
#Test
void routeOne() {
def job = new MyJob()
def myServiceA = new Object()
def expectedParameter = "Name"
def wasCalled = false
myServiceA.metaClass.doStuff = {someParameter ->
assert expectedParameter == someParameter
wasCalled = true
}
job.myServiceA = myServiceA
//Setup data to cause myServiceA to be invoked
job.execute()
assert wasCalled
}
Then repeat this process for all of the routes you have through your Job. This way you can isolate your tests down to the smallest part possible and test the logic of the object that you're invoking not the services it is using. I would assume you're using a service because the logic in there is being used by another part of the system. If you're testing the service through this job and for some reason the job goes away then you have to re-write your tests to invoke the service directly. The way that I've proposed you have tests testing the service directly and tests that mock out those service calls. If the job goes away you would simply delete the tests associated with it and you won't loose any test coverage. Kinda long winded but that's how I would approach testing it.
I upgraded a grails app from 1.2.2 to 1.3.7 after this upgrade a few integration tests have started to throw the following error the 'validateAndSaveList' is a method on a service used by the service I'm testing. These tests were passing before the upgrade and they will also pass if I run just the integration test phase with grails test-app -integration
junit.framework.AssertionFailedError:
No more calls to 'validateAndSaveList'
expected at this point. End of
demands.
Code:
import com.e.domain.*
import com.e.exception.GORMServiceException
import com.e.controller.SecurityUserCommand
class AccountServiceTests extends GroovyTestCase
{
def accountService
void testRegisterWithMinimumInfo()
{
def clinic = new Clinic(name:'clinicName')
def securityUserCommand = new SecurityUserCommand(username:'username', password:"password", confirm:"password")
def clinicUser = new ClinicUser(firstName:'fname', lastName:'lname', emailAddress:'abc#abc.com')
clinicUser.clinic = clinic
//clinicUser.securityUser = securityUser
clinic.address = new Address()
// TODO - JsecUser no longer in use
def role = new ShiroRole(name:'TEST')
//def subscription = ESubscription.findByName('Charter Member')
def subscription = new ESubscription(
name:'Charter Member',
description:'Charter Member',
periodType:'Monthly',
numPeriods:12,
amountPerPeriod:25.00,
electronicSubmissionRate:0.00,
accountingRate:0.01,
numAllowedUsers:4,
startDate: today -1,
endDate: today+1
)
subscription.save(flush:true)
if(subscription.hasErrors())
println subscription.errors
assertNotNull subscription
clinicUser.empathicCustomerProfile.subscription = subscription
def result = accountService.register(clinic, securityUserCommand, clinicUser, role)
assert result.success
assert result.clinic.id
assert result.securityUser?.id
assert result.clinicUser.id
}
StackTrace
junit.framework.AssertionFailedError: No more calls to 'validateAndSaveList' expected at this point. End of demands.
at grails.test.MockClosureProxy.doBeforeCall(MockClosureProxy.java:66)
at grails.test.AbstractClosureProxy.call(AbstractClosureProxy.java:74)
at grails.test.GrailsMock$_createMock_closure1.doCall(GrailsMock.groovy:125)
at com.e.service.AccountService.register(AccountService.groovy:46)
at com.e.service.AccountService$register.call(Unknown Source)
at AccountServiceTests.testRegisterWithMinimumInfo(AccountServiceTests.groovy:53)
this answer comes from working the issue out in the comments:
the exception you are getting clearly indicates that somewhere you have put a mock object in your service, and the service is calling the mock object in a way it was not set up to handle.
The root problem as seen from #hvgotcodes is that there was a mock object for the service even though in that given test there was no mocking happening.
This happened in grails 1.3.7
I found a unit test that was doing the following:
def dataBindServiceControl = mockFor(DataBindService)
dataBindServiceControl.demand.safeBind{}
dataBindServiceControl.demand.extractPhones{}
dataBindServiceControl.demand.validateAndSaveList{l-> return true}
def dataBindService = dataBindServiceControl.createMock()
controller.dataBindService = dataBindService
If those tests were removed then all the integration tests would pass so to solve with out rewriting the tests I added the following to the tear down method.
GroovySystem.metaClassRegistry.removeMetaClass(DataBindService)
With this addition the tests are now working correctly in grails 1.3.7