Pick a selector by "hierarchy" on "type" actions

[mateusjatenee]

One of the current issues with Magic Test is during form filling.
Right now, it finds each input through it's name attribute. That needs to be changed because in certain cases (like Livewire, Vue or React) the inputs don't have a name attribute.

I'm still unsure of the best way to handle this — I think a reasonable way is to send an array with all of the input's attributes to the back-end and have it figure out which selector it should pick. So, if there's a name attribute, use it. If not, look for the ID. If not, the wire:model, v-model, etc... and then if nothing's found just go with the classes. Something like that.

In the back-end I think it'd be good to have a Selector object that can generate a string for Dusk's methods, like #someId for IDs, input[wire:model=something] for Livewire (in case there's no ID or name), etc.
From the top of my head, the order would be:
Dusk (dusk="something"), name, id, v-model and wire:model, class

I'm planning to figure this out and also refactor the JS code on saturday, but if anyone wants to tackle that first it'd be awesome 👍

[ninthspace]

I've had to use generated dusk attributes in places when I need to target a specific field in an instance of a repeated Livewire component, e.g. dusk="field{{ $someKey}}" It's not hard, but it makes writing tests manually really slow. Repeated instances are problematic because their id, name or *model fields may be non-unique, so if you don't create dusk attributes the only way you'll know for sure which element you're targeting is by finding it through the DOM hierarchy.

When I know where I am in a document, but still want to use id or name attributes, I then use $browser->with('.some-selector') because that at least scopes subsequent selectors.

[mateusjatenee]

That's an excellent point. Do you have any examples of how do you scope it with with?

I'd love to have Magic Test automatically figure that out. I think one option is, on every event, iterate through each attribute and pick one that doesn't have conflicts. If none is found, then scope it.
I do think it's a bit problematic to add with to the Parser right now. It's a bit messy and I'll try to rewrite some of it on the weekend, along with the JS client.

[ninthspace]

The following image is an excerpt of screenshot from a website I'm developing. There are lots of nested Livewire components.

and here's a test that produces that screenshot:

    public function testCanAddWarehouseItemToJobTemplate()
    {
        $this->browse(function ($browser) {
            $browser->visit(new JobTemplateIndex())
                    ->createJobTemplate('JobTemplate 3')
                    ->with('@line0', function ($line) {
                        $line->type('quantity', 3);
                        $line->type('@text', 'e');
                        $line->waitFor('@searchBarMatches');
                        $line->keys('@text', '{arrow_down}', '{arrow_down}', '{enter}');
                        $line->waitUntilMissing('@searchBarMatches');
                        $line->pause(500);
                        $line->assertInputValue('@price1', '2.00');
                        $line->assertInputValue('@price2', '1.60');
                        $line->assertInputValue('@price3', '1.00');
                    })
                    ->assertSeeIn('@totalExcludingVat', '5.00')
                    ->assertSeeIn('@totalIncludingVat', '6.00')
                    ->click('@saveTemplate')
                    ->waitForReload()
                    ->with('@line0', function ($line) {
                        $line->assertInputValue('quantity', 3);
                        $line->assertInputValue('@text', 'Item 2');
                        $line->assertInputValue('@price1', '2.00');
                        $line->assertInputValue('@price2', '1.60');
                        $line->assertInputValue('@price3', '1.00');
                    })
                    ->assertSeeIn('@totalExcludingVat', '5.00')
                    ->assertSeeIn('@totalIncludingVat', '6.00');
        });
    }

Here I give each "line" a specific dusk attribute so I can identify them as @line0, @line1 etc., and then use with to scope that particular element. In the above example, I also identify each "price" with a dusk attribute, so for example, the price that appears on the page alongside "Retail Price" is identified as @price1, "Trade Price" as @price2 etc.

Of course, you can't rely or require dusk attributes to be present, so you'd probably need to scope via :nth-child.. selectors.

[mateusjatenee]

Ahh, gotcha. I was wondering how you were scoping it.
I think Magic Test can definitely support this. The first step IMO is supporting attribute hierarchy — it requires some JS rewriting and I plan to do it this weekend.

Now the trick is figuring out how to get the correct selector to use on with(). I also have a PR #12 to introduce AST parsing, so that'd probably help with the with statements.