pat / combustion

Simple, elegant testing for Rails Engines
MIT License
708 stars 51 forks source link

Generator integration #74

Closed tf closed 8 years ago

tf commented 8 years ago

Combustion works really well for me so far. There are some situations though where I would like to run a generator inside the dummy app and was wondering whether turning this into a Combustion feature might be helpful. For example:

In both cases, I would prefer not to commit the changes made by the generator, but rather regenerate on every Travis run to ensure the steps lead to a working setup with the current versions of the gems. In development mode, on the other hand, I'd prefer to generate once and reuse git ignored files on subsequent test runs to speed things up.

I could imagine passing a list of generators to Cumbustion.initialize!. But I'm not sure whether those should actually make changes to spec/internals or maybe some other ignored directory.

Do you think a workflow like that might make sense in the context of combustion?

artofhuman commented 8 years ago

Hi @tf. I have the engine which depends on active admin. And in every build i recreate application. But i not use combustion in this engine. It`s may be useful for you: https://github.com/artofhuman/activeadmin_settings_cached/blob/master/spec/spec_helper.rb#L19-L21

https://github.com/artofhuman/activeadmin_settings_cached/blob/master/spec/support/rails_template.rb

tf commented 8 years ago

Hi @artofhuman, thanks for the example. I am also doing something similar in another non Combustion project. But I was wondering if we might be able to simplify things by having Combustion take care of it.

pat commented 8 years ago

Tim, this certainly sounds useful. I wonder if it's better to keep it separate from Combustion.initialize, but likely to be invoked directly after that? Combustion.generate perhaps?

The one thing I'm wary of is if these generators require user input. Granted, I'd expect this to generally not be the case, but would be great to handle these situations in case people make mistakes or a generator's behaviour changes unexpectedly.

tf commented 8 years ago

Hi Pat,

thanks for your answer. Most generators that I'm aware of allow to replace manual input with command line flags of some sort. So that should not be a big issue.

I'm mainly not sure yet, where those generators should output files. spec/internal is almost like a dummy application, but often a lot more minimal - which is good, but might trip up generators which expect to be run in the context of a standard Rails app. Also this would mean mixing generated files, which should best be git ignored, with manually edited files. That does not really feel right.

pat commented 8 years ago

Hmm, where to output the generated files is a tricky thing. I was thinking in spec/internal, but if you're not committing those files, then yes, that could get confusing. No better solution comes to mind, though…

tf commented 8 years ago

There could be an option to have an ignored spec/dummy directory which is bootstrapped with the files from spec/internal. That way generators could create files there. I'm not sure though if that could mean a too fundamental departure from the core ideas of Combustion.

pat commented 8 years ago

It does feel like a stretch - if you're wanting a full app, then maybe the non-Combustion path is the easier one?

That said, I'd be open to Combustion working with both the current approach (minimal app, only what's necessary in spec/internal) or a full app in spec/internal and Combustion just provides a unified interface.

Given you've got some gems that take the non-Combustion path: how do you manage testing against multiple versions of Rails in those situations? Do you generate spec/dummy every time?

tf commented 8 years ago

Yes. spec/dummy is ignored. Additionally I generate to spec/dummy/rails-4.2.0 etc to allow for multiple environments in development. I do some custom environment variable magic at the moment, where I probably should have used Appraisal instead.

Since everything works at the moment, I would be hesitant to port the app to Combustion even if full app support was a thing. And for the cases where I am using Combustion, I do not have an urgent need for generator integration.

So maybe the best idea is to keep Combustion focused and look into extracting something new from my existing app once I again have the need for the full app scenario.

Thanks for the helpful discussion. Feel free to close this issue.

pat commented 8 years ago

Great to have the feedback :)