There are a few general patterns I noticed and which we could choose to follow as a paradigm. I also included some other sites (adidas, ZARA, and Opening Ceremony) which don't fall into these categories and show other options.

Simple designs

These are pretty basic and minimalistic in their styling. A good option if we want to keep things very clean and simple.

• Goodfight
• Chivichivi

Two panel block designs

Have a design where the product image takes up one half of the screen and the description takes up the other half. Superfluid uses some pretty interesting animations and it's worth taking a look at their site

• Superfluid
• JACQUEMUS
• Won Hundred

Designs with borders

Greater use of borders to separate sections. Balenciaga also does this, but to an even greater degree.

• Senteurs d' Ailleurs
• Unrun

Full width image

Product image takes up the full width of the screen with the description super imposed. Might not work as well with the kinds of product images we'll have.

• PHAEDIS

This pull request covers a lot of files, but what it aims to accomplish is to set up our testing environment, set up continuous integration, and layout the scaffolding for our project.

• Testing environment
  • This covers the jest installation changes in package.json, the jest configuration in jest.config.js
• Continuous integration
  • This will allow GitHub to automatically run our tests on a pull request and prevent merging if tests are failing. However, since we are all admins if this becomes annoying we can always force a merge regardless of any missing requirements such as failing tests or a missing code review.
  • .github/workflows/test.yml contains the script that GitHub will use for CI
• Project scaffolding
  • I wanted to set this up to make sure that our tests were working correctly. It also shows the test file structure we can choose to use: a Component.test.js file right next to Component.jsx. Jest automatically finds all these files when we run npm test. We can also set up jest in our script with the --watch flag to keep testing running in the background.
  • For end to end tests and integration test we might want to create a tests directory to contain these later
  • Added some linebreaks to index.html
  • I created aliases for our paths in webpack.config.js. This means that instead of doing something like

  import App from '../../App/App.jsx';
  

  we can just do

  import App from 'App/App.jx';
  

  Aliases are set up for all the main component directories.

• .gitginore
  • I added some changes here as well
  • The main thing is we should not be tracking compiled files in our client/dist directory (i.e. main.js).
  • I also added the coverage directory. When you run npm test you will notice a new coverage directory which contains the coverage report from jest. This is an option I have enabled. We can turn off coverage reports if they're not wanted.

@hangyin2020 @zman811 I make the following calls to the API:

• GET to /products/:product_id
• GET to /products/:product_id/styles

I also need the number of reviews for :product_id and the rating for :product_id

Shared information

• GET to /products/:product_id
• GET to /products/:product_id/styles
• GET to /reviews/meta:id

Switches Carousel to follow a controlled component paradigm. The props scrollIndex and onScroll are used to achieve this.

scrollIndex tells Carousel the index of the first element from items that it should display. The number of subsequent items to be displayed is then determined by size.

The onScroll prop takes a function and is used to provide Carousel with an event handler that can inform the parent component of clicks to the buttons in Carousel. Carousel reports what scrollIndex should be to reflect the change represented by the button clicks by passing this value to the onScroll handler. That is, a button click triggers a call to onScroll with the argument index, where index reflects the value scrollIndex should take to reflect the button click.

These changes were necessary in order to enable the programmatic control of the Carousel, e.g. changes to Carousel that should be triggered by user interaction in a different component.

A general carousel component to capture the functionality needed in #44, #45, and #47. Should be at least take a prop to indicate how many child components should be displayed at a time and a prop consisting of an array of all the components that should appear in the carousel.

Each product has an average rating based on its reviews. The average rating of the product will be represented by an array of solid or outlined stars, where the number of solid stars represents the review score. A total of 5 stars should always appear. The number of stars filled in should correspond to the average score.

The visual for rating should be representative of up to a quarter of a review point. For example, if the average is 3.8, this should display as 3¾ solid stars and 1¼ outlined stars.

Next to the star rating, a link stating “Read all [#] reviews” will show. The total number of reviews should be inserted in place of [#]. Clicking this link should scroll the page to the Ratings & Reviews module.

If there are no reviews, this entire section should be hidden.

Adds a basic carousel for use across the app. Currently takes two props:

1. items: an array of the items that the carousel should scroll across
2. size: the number of items that the carousel should display on the screen

Still to be implemented is the styling as well as a third prop direction which will dictate whether the carousel should be arranged in a row or a column.

Another improvement would be hiding the increment/decrement buttons at end of range states.

In this pull request, I added the basic file structure as well as some basic placing of elements on the page in the right spots. If someone could look over the file structure as well as the basic styling that would be great

• [x] #9
• [x] Pull out the color scheme and typography
  • [x] Light and dark mode colors
• [x] Save pictures of design for reference

Typography

• body text: AdihausDIN
• slant caps: AdiahusDIN Cn
• bold: AdineuePRO

Color Scheme

• background: white #FFFFFF
• text: black #000000
• flip for dark mode

Red: StyleSelector

• Adds the basic functionality for the style selector component.
• Allows clicking on a style to switch selected styles, which will populate its information into the product information.
  • Later this will also affect the AddToCart and ImageGallery components.

• Blue: ProductInformation
• Red: StyleSelector <-- (this PR is for this component)
• Green: AddToCart
• Yellow: ImageGallery
• Purple: ProductDetail (this may go in ProductInformation ultimately)

Relevant to:

• #22
• #30
• #31
• #32

Sets up fast refreshing of the react app on our server. I installed the necessary packages and performed the necessary configuration. Also cleaned up our package.json scripts. The get development up and running all you need to do is run npm run start:dev and visit localhost:3000 or whatever port you are using locally. The page will automatically update on save.

Line numbers for error in the browser are not properly source mapped. Explanation here.

@FECTeamOne/serum Until I have time to handle this, the errors in the console may be more informative:

Resources

A collection of useful resources, some of which are repeated in the guide below. If it's not clear what all these terms mean, look to the guide.

Matchers

• General Jest matchers
• Extended matchers for the DOM

Queries

• Reacting testing library query recommendations

Triggering events

• userEvent

Best practices

• Common mistakes (from the creator or React testing library)

Guide

Jest

Jest is a test runner. It provides the describe and it/test (these two are interchangeable) functions. It also provides functions like beforeAll, beforeEach, afterAll, afterAll in case you want to perform some actions before each of your tests (i.e. before each it block) in a given describe block, or once before all of them, or after each, etc. We use jest to run all of our tests using npm run test (this script calls jest).

Matchers

Jest also provides matchers like .toEqual which are check whether some value meets a condition. If we want to assert a particular statement we write something like expect(number).toEqual(4). You can also negate a matcher: expect(number).not.toEqual(4).

• List of Jest matchers

As a technical point, note that these matchers are methods on the object returned by the function expect which is provided by Jest.

React testing library

Jest is a general test runner that can be used for any javascript code. React testing library implements helpers to make the specific case of testing a React app easier.

Accessing components

With React testing library you access things on the "page" through queries (there is not actually a page during the test, instead a simulated browser page called the virtual DOM is created in the jsdom testing environment that we selected in our jest config).

The philosophy of React testing library is to simulate the way that a user would use the app during testing. This means accessing components by searching for their text or some visual component the way you would when interacting with a webpage. For example if we wanted to do something with a submit button that had the text 'Submit', instead of doing querySelector() for some css selector that would identify the button, we use utilities from React testing library to find it by its text. In this case we might do

const submitButton = screen.getByText('Submit');

where .getByText is the query that we're using. We can provide a string or regular expression to a query.

React testing library provides recommendations on which queries to use:

• Reacting testing library query recommendations

That page also include a summary table of the types of queries provided by React Testing library.

Some important helpers

• render: This is used to render your component to the testing environment just the way that in our app we render a component to the document. It substitutes for React's render function during tests.
• screen: This serves as a substitute for document during the test. Whereas in a webpage you might do document.querySelector() to find an element, in a test you would do screen.getByText() or some other query method.

Additional matchers (jest-dom)

There is a companion library to React testing library called jest-dom which extends the matchers from Jest to include matchers that are more useful for tests on a "webpage" (or more accurately the virtual DOM). These include matchers like toBeVisible or toContainElement. See below for the full list:

• jest-dom matchers

Simulating user interaction

React testing library supplies the basic function fireEvent to simulate user interaction, but recommends that the companion library user-event be used instead for simulating user events. user-event provides a more faithful recreation of the kinds of event that actually occur in the browser and so can help catch bugs that might otherwise slip through.

• How to use user-event

Testing layout

We can use this naming convention to structure our test files.

• Root describe: the name of the component you're testing
• Nested describe (you probably won't even need these): must have the when prefix to indicate a specific case (i.e. 'when user exists')
• Test in an it block: a sentence describing the behavior

Here's an example from the Carousel tests:

describe('Carousel', () => {
  it('should show the correct number of items', () => {
    // test goes here  
  });

  it('should scroll on button click', () => {
    //test goes here
  });
});

Getting started

When you're getting started on a component you can fill out your test files with todos that will test for all the specifications for that component:

describe('Component', () => {
  it.todo('should meet specification #1');
  it.todo('should meet specification #2');
  // ...
});

Note that you can't provide a 2nd argument (the testing callback) to an it.todo or you'll get an error. If as you're working you have a broken test that you don't want to run, you can change 'it(...) to it.skip(...).

Testing example

Suppose we have a Component component that contains two buttons. One of the buttons says 'Click Me!' on it and the other says 'Enabled' on it. When you click the 'Click Me!' button the text on the other button should change to 'Disabled' and the button itself should become disabled. The implementation of Component does not actually matter for how we write the test, as you'll see.

1. First we have to import our component and screen from React testing library (due to an issue with global importing of screen that I was unable to resolve). You won't need to import any of the other testing utilities since that is taken care of in a test setup script that runs before each test. If there's anything additional you need to import that you think would be useful across our test suite, add it to the test setup script (client/src/tests/testSetup.js).

import Component from './Component.jsx';
import { screen } from '@testing-library/react';

2. Arrange: We need to set up the elements that we are going to test. We use render to actually add the element to the virtual DOM. Note that this is actually the render from React testing library, not ReactDOM.

describe('Component', () => {
  it("'Click Me!' button should disable the other button on click", () => {
    render(<Component />;

    // rest of testing code will go here
  });
});

3. Act: Now we simulate user interaction. We need to make some modifications to our code above to trigger simulated events:

describe('Component', async () => {
  it("'Click Me!' button should disable the other button on click", () => {
    const user = userEvent.setup();
    render(<Component />;

    // rest of testing code will go here
  });
});

Now we can trigger our event:

await user.click(screen.getByRole('button', 'Click Me!'));

We use getByRole as recommended by the query priorities, although this requires that you use the type="button" attribute on your button to provide adequate accessibility. If you don't do that you can instead do screen.getByText('Click Me!').

4. Assert: Finally, we use matchers to check that the proper behavior has been achieved.

expect(screen.getByText('Disabled').toBeDisabled();

In all, this would be the test

import Component from './Component.jsx';
import { screen } from '@testing-library/react';

describe('Component', async () => {
  it("'Click Me!' button should disable the other button on click", () => {
    const user = userEvent.setup();
    render(<Component />;

    await user.click(screen.getByRole('button', 'Click Me!'));

   expect(screen.getByText('Disabled').toBeDisabled();
  });
});

Fixing a test

The most useful tool might be screen.debug(). Put this in your test somewhere and it will console.log the state of the virtual DOM at that moment.

The user should be able to filter reviews based on star, unlike sort, this will ONLY show what matches not just move it to the top.

• [ ] Should allow filtering based on start count
• [ ] The filters should be additive (1 and 2-star reviews at once)
• [ ] add text to show what filters are being applied and have the option to remove all