Add `attributes` as a name to the v4 blacklist for DSL definitions about site_prism HOT 9 CLOSED

Released in v4.0.beta - Initially disabled as a configurable option

cc/ @kouno

from site_prism.

This is an intractable problem and solved by your load order being incorrect.

the RSpec defined matchers allow us to use our metaprogrammed matchers inside RSpecs metaprogrammed assertion logic.

I would look at your stack and see if you can isolate your logic. Or failing that control your load order more succinctly. You are encountering the same issue as anyone else would when overwriting any protected method name

from site_prism.

@luke-hill First, thanks for coming back on this and taking the time to look into this! :)

However, I don't think this is a loading issue.

SitePrism can override the default RSpec matcher for have_attributes which breaks tests that have nothing to do with SitePrism. Once the class is loaded, and the matcher setup, it is not possible to go back to the previous behaviour.

I'm not sure why SitePrism defines its own matchers at all since I would expect the have_ default matchers to just work as expected in the current implementation. SitePrism defines has_ methods on the page object and should already plug nicely with RSpec.

Maybe I'm just missing a piece here on why these are necessary... Do you know why that would be?

from site_prism.

I'm not going to lie, that area has changed a lot recently. So if you're having problems, I need you to perhaps dig a bit deeper into it as I don't have time at the moment.

If memory serves me right, this was to allow us to do complex matching. and also to add a negative matcher (Which is needed to be custom, as it deviates from RSpecs default ! behaviour).

It seems as though what you're proposing is to remove the positive matcher. Now if this has no adverse effects, and you can reconcile the unit tests / feature tests (I'm aware we have 2 failing ones on old firefox). Then I'm not against some changes being made.

I hope that helps. I'll leave this open for some discussion if needed.

from site_prism.

If memory serves me right, this was to allow us to do complex matching. and also to add a negative matcher (Which is needed to be custom, as it deviates from RSpecs default ! behaviour).

Are you speaking of the have_no_* matchers? I know that Capybara has the right behaviour when using negations but I probably would need to crosscheck how that is implemented and if it would work as expected with SitePrism.

Reference:
https://github.com/teamcapybara/capybara/blame/f43b6499ecb2721dd97b63a7fe31ff2518b89b4c/README.md#L805-L811

from site_prism.

Any thoughts on this @kouno

At the moment I'm spending a lot of time tackling some internal tech debt around capybara restrictions. Once that is finished I need to cut a stable v1 of the all_there gem. So that's gonna keep me tied up for a while.

from site_prism.

@luke-hill I don't think there is much urgency to fix this bug yet so feel free to leave on the side for now.

I'll make a PR when I'm ready and have gotten cucumber tests running locally.

from site_prism.

So re-reading this now we have 2 avenues.

1. Add attributes to the blacklist (We are creating one), that will be released in v4. I personally think it's a very weird name for a section.
2. Somehow Scope the RSpec matchers. I don't believe this is possible, so #1 looks like the only solution. For v3 we can add a deprecator in. I would probably make it passive (As I plan on cutting v4 soon). So it would be soft-deprecated in v3, and hard deprecated in v4.

I do plan on committing a bit more time to work on this where time allows. I'm also pushing a bit on the funding route now, as I've seen how it can help from other avenues.

from site_prism.

@kouno Having spent some time off recently, I've come back to this. I think the best thing is add this to the blacklist. Which whilst masking the issue I think is probably the best one. As it'll also allow us to be stricter with other names we don't want in the blacklist (Such as special characters e.t.c.)

from site_prism.