Should commands be chained off of assertions?

[adamalston]

Both of the following code snippets work as far as asserting that a field is enabled before selecting an option in it. My question has more to do with what is the recommended approach for this flow - should commands (select, type, check, etc.) be chained off of assertions?

Scenario 1 - Assertion and selection are done separately:

cy.get('[data-testid="some-attr-here"]').should('be.enabled');
cy.get('[data-testid="some-attr-here"]').select('some-file');

Scenario 1 - Assertion and selection are done together:

cy.get('[data-testid="some-attr-here"]').should('be.enabled').select('some-file');

should is a command in and of itself so technically the second scenario is just two commands chained off of each other. I'm curious what is recommended and/or considered a best practice here.

[jjhelguero]

In most cases, the .should() will yield the same subject so requiring for the same element in this case is not necessary. In my opinion, second scenario would be better.

[humbienri]

I'm inclined to recommend the 1st way of doing it. Seems to me that the newer tools (Playwright/Cypress) don't like to recommend a separating between the actions and the assertions and I think this muddies up the water and makes the tests more difficult to discern as to intent.

This was more recommended in the past, with other tools, as the automation part of the test was done with one library and the running and asserting of the test was done with another library, think JUnit or NUnit and Webdriver. But I think that made it easier to see the purpose of the test more easily.

Furthermore, if the .select API, as used above, is already doing an "actionability" check as to whether the element is enabled and "usable" then it seems redundant and further obfuscating the test, then why inject the .should in there yet again.

Old school.