Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Flapdoodle Embedded MongoDB for integration tests #436

Merged
merged 1 commit into from Mar 25, 2016

Conversation

Projects
None yet
2 participants
@vpavic
Copy link
Member

commented Mar 20, 2016

This resolves #419.

I've signed the CLA.

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 20, 2016

Closing & re-opening to force a new CI build.
Failure seems unrelated to these changes, the build passes for me locally.

@vpavic vpavic closed this Mar 20, 2016

@vpavic vpavic reopened this Mar 20, 2016

@rwinch

This comment has been minimized.

Copy link
Member

commented Mar 20, 2016

Thanks for the PR! I wonder if we want to enable this for the sample applications too? What are your thoughts @vpavic?

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 20, 2016

@rwinch I've considered using this in sample app too but eventually decided to limit use to integration tests.

My reasoning was the following:

  • Flapdoodle on its website clearly states the project is aimed at running Mongo in tests so we should follow this
  • IMO sample apps should provide a realistic use case of how to use the framework
  • sample apps include instructions on how to browse the session data using clients for underlying technology used to persist sessions, meaning you need Mongo (client at least) anyway to fully benefit from sample app (and I don't know how Mongo client would work with an embedded Flapdoodle instance)

This is in contrast to JDBC samples for example, which use H2 database, since H2 is full-blown RDBMS which also offers easily embeddable web client.

@rwinch

This comment has been minimized.

Copy link
Member

commented Mar 21, 2016

@vpavic Thank you for your feedback. I somewhat see your point about the samples needing to provide a realistic experience for users. However, we do not want any extra noise for setting up samples.

Fladoodle should certainly not be used in production, but I think it is ideal for helping users run a sample application. We are testing the sample with Fladoodle so that is how users should experience it (since we know that is what works).

Finally Fladoodle is just downloading the executable and forking a process that starts up a full fledged Mongo instance. This means that this does not differ much from using an embedded relational database.

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 21, 2016

@rwinch if we go with Flapdoodle to back the sample app, what happens with the part of the guide that describes usage of Mongo client to query and alter data (how does it work section)?

@rwinch

This comment has been minimized.

Copy link
Member

commented Mar 22, 2016

@vpavic You can still connect to mongo when using Fladoodle using any Mongo client.

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 22, 2016

@rwinch yes, I'm aware of that. But if you have Mongo client it's highly likely you also have Mongo server installed as well, that was one of my arguments for not moving sample app to Flapdoodle.

But OK, if that's your preference I'll move the sample app to Flapdoodle.

There's one more thing that crossed my mind today, and I've completely neglected it during initial implementation - embedded Flapdoodle instance needs to use random port to avoid any potential conflicts. That means in sample app scenario we also need to communicate this port to the user - is logging the port on startup good enough for this?

@rwinch

This comment has been minimized.

Copy link
Member

commented Mar 22, 2016

@vpavic Thanks for the response.

But if you have Mongo client it's highly likely you also have Mongo server installed as well, that was one of my arguments for not moving sample app to Flapdoodle.

That is fair. However, I think there are many people that will not care about performing the steps with the client (they just want to get it running). We should have a disclaimer that you must have a client installed within the guide.

That means in sample app scenario we also need to communicate this port to the user - is logging the port on startup good enough for this?

This is an option. Alternatively (and probably preferably), we could default the port to using the standard port and ensure our test configuration overrides this to a random port.

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 22, 2016

We should have a disclaimer that you must have a client installed within the guide.

OK.

Alternatively (and probably preferably), we could default the port to using the standard port and ensure our test configuration overrides this to a random port.

Even though this means sample app fails to start for users that run Mongo instance locally? This is somewhat in contradiction to "we do not want any extra noise for setting up samples" argument.

@rwinch

This comment has been minimized.

Copy link
Member

commented Mar 22, 2016

@vpavic

Even though this means sample app fails to start for users that run Mongo instance locally? This is somewhat in contradiction to "we do not want any extra noise for setting up samples" argument.

That is a good point. Let's stick with logging. Perhaps it could even log "if you have the mongo client installed this is the command to connect"?

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 22, 2016

@rwinch yes, that should be doable. I'll look into it and update the PR accordingly soon.

@vpavic vpavic force-pushed the vpavic:improve-mongo-it branch from 65185b3 to ed08593 Mar 22, 2016

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 22, 2016

@rwinch I've updated the PR, please review the changes.
I still need to update the guide. I'll take care of this when we finalize the implementation.

*/
@ContextConfiguration
@DirtiesContext

This comment has been minimized.

Copy link
@rwinch

rwinch Mar 23, 2016

Member

Just curious why @DirtiesContext was necessary

This comment has been minimized.

Copy link
@vpavic

vpavic Mar 24, 2016

Author Member

Good thing you pointed this out, @DirtiesContext can be removed now.

I've had issues similar to ones described in #396 with my initial implementation, since I had static port config for embedded MongoDB instance.

Moving to randomly assigned port fixed this.

@rwinch

This comment has been minimized.

Copy link
Member

commented Mar 23, 2016

@vpavic Thanks for the fast turnaround. Overall looks good. I had one comment inline. When you update the documentation make sure that the guide either does not show the Flapdoodle config or it describes that this is just necessary to start mongo and not going to happen in a real world example.

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 24, 2016

@rwinch

When you update the documentation make sure that the guide either does not show the Flapdoodle config or it describes that this is just necessary to start mongo and not going to happen in a real world example.

Yes, of course. Mongo-related config in sample app is in a separate @Configuration class, the original @Configuration class that contains asciidoc tags was left untouched.

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 24, 2016

It completely slipped my mind that we could use Spring Boot's auto-configuration for an embedded MongoDB instance. I'll change this in next update.

@vpavic vpavic force-pushed the vpavic:improve-mongo-it branch from ed08593 to f2017aa Mar 24, 2016

@vpavic

This comment has been minimized.

Copy link
Member Author

commented Mar 24, 2016

@rwinch I've updated the PR with the documentation/guide.

I also tried the Boot's Embedded MongoDB auto-configuration support, however I've run into spring-projects/spring-boot#5487. Not to confuse the users with this exception (even though its harmless as it occurs on shutdown) I've decided to stick with manual config until this gets fixed in Boot. Your thoughts?


UPDATE:

Somehow I managed to miss the fact that this exception on shutdown also happens when we use manual conf. So I'll update this to auto-configuration anyway. Also it appears that nothing within Boot itself would be able to fix this behavior.

@vpavic vpavic force-pushed the vpavic:improve-mongo-it branch from f2017aa to 903cac4 Mar 25, 2016

@rwinch rwinch added this to the 1.2.0 milestone Mar 25, 2016

@rwinch rwinch merged commit 79928bd into spring-projects:master Mar 25, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@rwinch

This comment has been minimized.

Copy link
Member

commented Mar 25, 2016

@vpavic Thanks for digging into this so deep and for the quality PR! This is now merged into master

@rwinch rwinch self-assigned this Mar 25, 2016

@vpavic vpavic deleted the vpavic:improve-mongo-it branch Mar 25, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.