FieldKit Tab: Test for FieldKit Sub-Tabs

[braughtg]

FarmData2 adds the FieldKit tab to the farmOS user interface.

This test should check that:

• [ ] - The FieldKit tab contains sub-tabs for “Info” and “Seeding Input.”
• [ ] - The order of the tabs is “Info” and then “Seeding Input.”
• [ ] - There are the correct number of sub-tabs (2 at this time).

Notes:

• The spec.js for this test should be created in the cypress directory in the fd2_field_kit directory.

Challenges:

• The HTML for these tabs is generated by farmOS and thus will not have data-cy attributes, and you will not be able to add them. Thus, you will need to do some research to find an effective way to cy.get the HTML element for the tab. The resources below may be helpful.
• Because, over time the UI may evolve and change (e.g. new tabs may be added) your tests should not rely on the specific ordering of the tabs in the UI. That is, you should be careful that your test would still pass if new tabs are added or the tabs are reordered. E.g. you should not rely on the BarnKit tab being the 3rd child of some other element.

Resources:

• Cypress Locators: The ways that cy.get finds elements in the page. We have used data-cy attributes up to this point. But there are other types of locators.
  • Cypress Locators : How to find HTML elements
  • Cypress Locators
• Cypress Selector Playground: The selector playground is part of the Cypress application that can help with finding and testing locators that can be used with cy.get.
  • Cypress Selector Playground
• Browser DevTools Element Inspector: A tool built into the browser’s DevTools that can help you find the source code for a specific element in the page.
  • Firefox Element Inspector

Additional Information:

Some additional notes relevant to this issue:

• The .spec.js file containing your test should be stored in an appropriate location and have a short but descriptive name. Use the locations and an naming from the "Good First issues" as examples.
• The .spec.js file should include a comment at the top that describes what the file as a whole is testing.
• The message for the describe should describe in a short phrase what the file is testing.
• After logging in and visiting the desired page the beforeEach method should call cy.waitForPage(). This will ensure that the page is fully loaded (e.g. that all the Maps used by the page are loaded) before performing any tests.
• It is not necessary to include a separate it for each of the things to be tested.
  • You should decide how to divide the things being tested into its so that each it tests a cohesive set of things.
  • The message for each it should describe in a short phrase what the it is testing.
• The .spec.js files in the farmdata2/farmdata2_modules/fd2_example/ sub-tabs (e.g. ui, api) may provide some helpful examples.
• These tests should utilize logs that are in the sample database. Information about the data contained in the sample database can be found in the "The Sample Database" section of the docker/sampleDB/README.md file.

[Zivanovic8]

Group 1 will work on this ticket.

[aidanbennettjones]

Since the HTML data generated on the page is done through farmOS, that means there will not be any "data-cy" attributes and they cannot be added. What are some effective ways to "cy.get" the HTML element for the tab? Is this time-efficient?

[anemervontage]

You can use alternative approaches for Cypress' "cy.get" which can include using unique attributes, IDs, classes, or CSS selectors associated with the tab element. It would work the same, and I don't think efficiency would be affected, but having "data-cy" attributes does make things easier.