/iconic

Automated Cypress tests for the Iconic website using Mockmock.

Primary LanguageTypeScriptGNU General Public License v3.0GPL-3.0

Iconic Automation Task

This repo uses Cypress to automate the Iconic website checkout flow.

Requirements

  • Node 20.x.x (LTS)

Setup

  1. Clone the repository
  2. Run npm install to install the dependencies
  3. Copy the .env.dist file and rename it to .env
  4. Run npm test to run the shopping cart tests

Alternatively run npx cypress open to open the Cypress Test Runner and run tests in headed mode.

Config

Configuration is handled through the .env file. The following variables are available:

  • ICONIC_MOCK_RECORD: (bool) whether or not to record and overwrite new mocks
  • ICONIC_MOCK_REPLAY: (bool) whether or not to replay mocked data
  • ICONIC_APP_URL: (string) The URL of the AUT
  • ICONIC_ACC_EMAIL: (string) The email address of a valid Iconic account
  • ICONIC_ACC_PASS: (string) The password of a valid Iconic account

By default the tests will run in headless mode and use mocked data.

All confugurations are valid, so you can also tell Mockmock:

  • to record new mocks while replaying old data (record: true, replay: true)
  • to ignore the Mockmock framework entirely (record: false, replay: false)
  • to record new mocks while ignoring any existing mocks (record: true, replay: false).

Mockmock (Not Implemented)

This repo also houses a copy of Mockmock, a Mocking framework I wrote while working at Carted that generates mocks based on any requests made from an AUT.

With enough time and proper access to the AUT, I would have liked to integrate Mockmock to demonstrate what autogenerated mocks from E2E tests look like, alas I needed to timebox this task due to having Xmas commitments.

Mockmock is agnostic about the AUT and thus, when recording, will record any and all results indiscriminately. This means if you are recording new mocks and run into an error (i.e. a 404 or 500) the mock will be recorded and future runs that rely on that mock will return that same result.

To avoid this, you can manually edit the offending result inside the mockfile (if you know the schema/shape) or try or a clean run.

It could be argued this is a design flaw! But if neither your AUT nor your tests are flakey this shouldn't be an issue, so in that sense it encourages good test design and fixing any bugs that affect your core product, since E2E tests should be used somewhat sparingly in the first place anyhow 😄 ⚡ 🚀

Task

Objective: Test the iconic website (https://www.theiconic.com.au/ ) to check if the basic functionality is working correctly.

Scenario: You are tasked with testing the shopping cart functionality of an e-commerce website. Your goal is to ensure that users can add items to their cart, view the cart, and proceed to checkout without errors.