Copy across attr_accessors and cattr_accessors

[zeisler]

Copy across attr_accessors and cattr_accessors

[zeisler]

Yes attr_* methods are not added to the mock. I've never yet needed them, but there is no reason we can't do them the same way I just added alias_attribute.

[markburns]

I think your goals and our goals may be slightly different. Not misaligned, just we are probably coming from completely different angles to different problems. We have a huge application with a test suite that takes (non-parallelized) about 2.5-3hrs. We still haven't successfully gotten active_mocker to get one of our full specs files to pass, but it is looking promising the tests we have seen passing are 100s or 1,000s of times faster.

Now I think I understand the goal of this project more, as I hadn't noticed the idea of mocking out user-defined methods until we had invested quite a bit of time in it.

Ideally if we can get active_mocker to copy across our application defined methods (and accessors etc) then we may be closer to cutting hours from the test suite time and retaining the same level of confidence. This will hopefully open up a completely different paradigm of development style and make everyone much happier. And ideally make a fantastic tech blog post too.

Now I would prefer to be in a situation where we have a smaller test suite where every unit test is a genuine unit test and dependencies are clearly defined and coupling is tiny. But the reality is we are looking for a drop-in replacement for AR on a large app that spins up lots of factories that spin up more factories etc. I'm a consultant and this pattern seems to be the most common on lots of Rails apps I've worked on. Probably because development of new features is easy that way, and it only gradually becomes a problem.

It seems feasible to pull in user defined methods by using Method#source_location and a configurable setting that just looks in app,lib etc. I've done something very similar before in https://github.com/markburns/delfos

Would you be open to a PR that supports copying these methods across into the mocks (maybe as an overridable thing)?

We'll probably be going ahead anyway with it, but it's always nicer where possible to stay aligned with the original author's thoughts on how/if something should be done.

[zeisler]

Supporting user defined method would mean you'd need to support the entire active record api, even running SQL strings. This would be an infinite amount of work. There is an assumption that included modules are safe to run, an assumption that I know is not always true, but non the less the way I've used it.

You could try moving your methods in modules.

Making this gem a drop in replacement for active record is not what I'm interested in, the support cost, besides the developer time would be to great.

[markburns]

Rather than e.g. SQL strings, which I agree would be painful to support.
What I'm really thinking of is being able to test methods like the ones you might suggest putting into modules.
Things that might depend on an associated object built with a factory and say iterate over and join some fields or something like that. Basically, simple methods only doing things with attributes and associations.

As far as I can see, all stuff that is supported already, but instead of mocking out methods allowing them to execute against the mocks and factory generated attributes and associations.

Then we can just run the specs, determine the ones that passed, then move these over to be our new active_mocker specs. Slash some test run times and allow focusing more time on improving other slower tests in other ways.

[markburns]

Maybe you are right that if it gets the 80% done and is really useful, then the support burden would become huge as the expectation to do the remaining 20% may be great

[zeisler]

Let me think about importing user defined methods into the mock. It's a big change in the current paradigm, but the functionally it's the same as running user defined method from modules in the mock. Really this would most likely leek over for the need for scopes too.

[markburns]

Absolutely. Actually it makes sense for us to at least try out putting some of the instance methods into modules to see how far we get with that approach. If it is only e.g. 2% of tests that end up passing this way then we'll probably want to rethink the strategy completely, and there is little incentive for us to try and drive this project in that direction. If it is 80% then there is a clear benefit (at least for us) to going down this route.

[zeisler]

Willing to accept a PR for this, but it does not provide any benefit for my self or enough benefit for the general user for me to develop.