FD2 Tabs: Test that Main FD2 Tabs Exist

[braughtg]

FarmData2 adds tabs to the farmOS user interface. The tabs that are added depend upon the user that is logged in.

This test must check that:

• - When a manager is logged in the UI should contain the FieldKit, BarnKit, and FD2 Config tabs.
• - When a worker is logged in the UI should contain the FieldKit and BarnKit tabs but not the FD2Config tab.
• - When the guest is logged in none of the three tabs should appear.

Notes:

• The spec.js for this test should be created in a directory named cypress in the farmdata2_modules 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.

---

Original issue by braughtg
Tuesday Apr 11, 2023 at 04:36 GMT

[Toddthegod1]

claimed by xxxToddTheGodxxx

[ngpmnam]

Since our team is responsible for this issue, we want to point out a little inconvenience we encountered. Since there was no hyperlink that led to the file containing the login information, we spent some time searching among the files listed. However, we also assumed the login username for the guest account will also follow the format of the manager's and worker's accounts: manager1 and worker1. Thus, we guessed the username for the guest account, which turned out to be just guest, might be guest1 or guest2 as well. Since the confusion is unnecessary, our team wanted to add a hyperlink to the file, which can be found here: https://github.com/DickinsonCollege/FD2School-FarmData2/blob/main/INSTALL.md