Generator best practices and testing considerations

I am extracting a piece of code to an engine that manages Discord slash commands via their webhooks from a project of mine. In the process, I’m creating generators for the Command classes that define/respond to those commands. Currently I have two generators install and command.

The former creates an initializer for the Discord application data and mounts the engine. It was fairly straight forward to test the creation of the initializer using Rails::Generator::TestCase but I’m not 100% sure how best to handle testing applying the mount. Currently I’ve got ye olde ruby code that creates a config/routes.rb file in the destination_root for me to insert_into_file but this seems like the sort of thing that a bazillion others have probably already done and I just couldn’t find.

The latter actually creates the command files themselves, inside app/bot. Testing this was relatively simple but I’m curious what folks would say are best practices when it comes to name-spacing things like test_framework generators.

For base rails things (controllers, models, jobs, etc.) I see that test frameworks generally get their own namespace (eg. test_unit:controller, rspec:job, etc.) but for new kinds of things, would it make more sense for it to live in the same namespace as the original (eg. discord_webhooks:command invokes discord_webhooks:test_unit:command, discord_webhooks:rspec:command, etc.) or should they get added to the test_framework namespace? (eg. discord_webhooks:command invokes test_unit:command, rspec:command, etc.) Or should I just do whatever and hide them so it’s mostly irrelevant?

TLDR;

  1. What’s the best practice to test generators that modify files rather than creating new ones? (eg. config/routes.rb)
  2. Should test_framework generators get the same namespace as the thing they’re making if they’re making non-standard rails things? (discord_webhooks:test_unit:command vs test_unit:command)
1 Like