Best practices for handling dummy app in engines

Tools Gems+Engines
1

This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.

Message originally sent by slack user U783AX2QZ9X

Curious if y’all have any specific patterns for dealing with the dummy app in engines. Do you have have a dummy app per engine? One shared dummy app? Something else?

2

Message originally sent by slack user U783ZNM0KD4

I have used https://github.com/pat/combustion a few times. However, most often I setup a dummy app per engine

3

Message originally sent by slack user U783ZNM0KD4

here is a blog post I recently added about setting up testing - https://hocnest.com/blog/testing-modular-monolith-engines/

4

Message originally sent by slack user U783AX2QZ9X

this post and the series are great! thanks for sharing! i was looking at combustion before and i couldn’t really tell what i’d gain by using it over the dummy app since it’s still generating a dummy app (albeit smaller).

5

Message originally sent by slack user U783ZNM0KD4

thanks <@U783AX2QZ9X>!

6

Message originally sent by slack user U783MOJYF8Z

cbra.info uses a dummy app per engine.

7

… cbra.info does because I never really ran into problems with this. Meaning, it’s been more of a “don’t care” for me rather than a “this is how it should be done.” I like the idea for combustion. For one dummy to rule them all. Heck, why can’t we write (most of our) engine tests without loading a Rails app… we’re going to run into this discussion at gusto pretty soon…

8

Message originally sent by slack user U783MOJYF8Z

Are you talking about having a category of tests that don’t depend on Rails?