Need some input for proposing various improvements

[pelletencate]

Hi! We've decided to make Cypress our first-stop system testing framework for our Rails app. We love working with CypressOnRails for its middleware.

I'd like to propose some improvements I'm working on that I'd love to contribute back upstream, but I'd like to be informed on use cases that other people have.

Factories

• I've created a factory command that immediately creates and yields one single factory.
• We created the possibility to directly send objects to associations in a factory's generator, so that we don't have to do the stuff documented https://github.com/shakacode/cypress-on-rails/blob/master/docs/factory_bot_associations.md to our factories. (I don't think my factories ought to be responsible for being compatible with CypressOnRails)

All in all, on my end I'm now able to write this:

beforeEach(() => cy.factory('merchant').as('merchant'))
// [...]
it('assigns a merchant!', function() {
  cy.factory('product', { price: 100, $merchant: this.merchant }) // TODO: Make it work without the `$`
})

I've currently hacked this around the commands, but it should obviously be part of SmartFactoryWrapper. I want to remove the $ eventually, making it smart enough to map keys to ActiveRecord classes and their associations.

Questions I'd like insight on

1. Factories

• Currently, the verb to the factory generator is configurable. Is there any reasonable case for a system test in which you want a factory to do anything other than create or create_list?
• Does anyone associate/nest objects in factories that arent ActiveRecord relations?

2. Security

• I want to turn app commands into POROs and map them by class name, so you can't simply run arbitrary code by pointing to any file. Is there any reason why it wasn't designed like this in the first place?
• To anyone using appEval: any good reason not to write a custom command instead?

[grantspeelman]

I don't think my factories ought to be responsible for being compatible with CypressOnRails
I would disagree on this statement, but suspect it will also depend on what you planning on testing using cypress.
We have a frontend end team writing our cypress tests and the less they know about FactoryBot the better in my opinion, exposing a simple to use factory can help hide implementation details if you plan to use Cypress for end to end testing. (We have had the pain of having to update many cypress tests because factories and model associations change.)
That said, would be awesome if it was possible to do this 😄 . I'll do my best to answer your questions.

Currently, the verb to the factory generator is configurable. Is there any reasonable case for a system test in which you want a factory to do anything other than create or create_list?
you can use build if you want a list of generated values you can use in your cypress test. EG filling out a form with valued values. That said, this is not documented anywhere.

Does anyone associate/nest objects in factories that arent ActiveRecord relations?
not that I know of

I want to turn app commands into POROs and map them by class name, so you can't simply run arbitrary code by pointing to any file. Is there any reason why it wasn't designed like this in the first place?
that is harder to get working in development mode with class reloading

To anyone using appEval: any good reason not to write a custom command instead?
"good" is subjective 😸 . You don't have to create a new file could be one reason. That said, when took over the gem a while back, it was something you could do, so kept it in for compatibility.

From a Security standpoint, it's still best to to not expose your local server and make sure to bind it to localhost.

[pelletencate]

Thanks for taking the time to consider and answer!

I suppose your perspective is at least as valid as mine, so forcing my (or anyone's) vision on what a factory should and shouldn't be responsible for is probably overly obtrusive level of being opinionated. (For the record: I 100% see the value of having batteries-included factories crafted for system tests). I'll take it on it being a really-nice-to-have feature that feels good to full-stack folks.

• The single-access factory command is literally a oneliner. Maybe I'll do a quick build/create/createList thingie so if I got a moment of procrastination one of these days, I'll add it to the generator and submit a PR.
• The association stuff is insanely hacky in my codebase so I'll need some "actual" time to refactor it.

This coming weekend I'll be swamped with regular work, but I hope to be able next weekend to do some work on the associations.

As for class reloading, I haven't tested this yet, but shouldn't it be as simple as adding them to the Rails autoloader and not requiring them? (No need for an immediate answer, I'll find out soon enough). Does your frontend team use appEval or write custom commands in Ruby? Would writing a class instead of a snippet be much overhead for them?

[grantspeelman]

we don't use appEval, it's the first thing I delete after installing the gem. I left it in the gem for backward compatibility. I think if I ever got around to doing version 2 of the gem, i would remove it.

[Splines]

@pelletencate In case you're interested, I've just implemented a small solution that allows to call FactoryBot like this from your Cypress tests (and also not worry about FactoryBot associations):

FactoryBot.create("assignment", "with_deadline_tomorrow", { file_type: ".pdf", size_max: 10 });

You can check it out in this repo.