Skip to content

Simple front-end + back-end service for consuming, calculating, and displaying basic code coverage

Notifications You must be signed in to change notification settings

Jakatut/Code-Coverage

Repository files navigation

Code Coverage

Project Requirements

  • Design an API that can:

    • Return a list of potential files
    • Return coverage information for a specific file
  • Design a Datastore that can:

    • Get Coverage for an individual file and version
    • Get the total coverage for an individual file.
    • Ingest code coverage data in the form of a JSON file.
  • Design a front-end application that displays:

    • A landing page with a list of potential files
    • A search bar that filters potential files (search within a full repo)
    • When a file is clicked, the file should be displayed with the percentage of code covered.
  • Technical Constraints:

    • The frontend must be ReactJS, preferably with TypeScript

Project Structure

The project consists of:

  • A frontend react application within the frontend/ directory
  • A backend golang (gorilla/mux) application within the backend/ directory
  • ! A .env file for environment variables with the backend/ directory. !

Backend

The backend contains:

  1. A datastore for repositories and code coverage

    • The datastore can create, read, and update code coverage and repository data
    • Just kinda mimics a db.
  2. Entities that are stored in the datastore.

    • These define the data contract for the rest API, mapping json names to members.
    • Define "business logic" for the entity. Things like calculating code coverage flattening data, etc.
  3. A REST API for repository data and code coverage data.

    • Code coverage can be ingested in bulk or single test formats. (i.e the entire json file you provided or single objects).
    • For the api basically just take the structure of a repository/directory. The data provided here maps to the directories in the repository directory defined by the .env file.
    • I think maybe the server should have just read the data and provided it, because this does get a bit confusing. I just think of it as a "fake sftp" server.

Error messages and codes are just a guess sometimes because of time constraints. Error handling/responses could be handled better, maybe with it's own model format instead of plaintext.

Frontend

The frontend contains:

  1. React context for repository data storage

  2. An API layer for communicating with the backend (repository and coverage)

  3. Visually, not much. Just a list of repositories, and the repository data. Clicking on a file will take you to the coverage page.

Frontend Setup

Install dependencies:

npm install

Start the application

npm run start # Runs on port 3000

Backend Setup

Setup environment variables

! This project uses a .env file for environment variables. !

Within the .env file at the root of the backend project, two variables can be found:

REPOSITORY_DIRECTORY= # The directory that contains the repositories for the server. 
                      # e.g. /home/user/FuzzBuzz/repositories

PORT=                 # The port the server listens on.

Install Dependencies

make install # Installs missing dependencies (go get)

Build

make go-build

Run

./bin/backend # In FuzzBuzz/backend. 

Data Priming.

Becasue of the "fake" sftp server design decision, some data needs to be primed for that, along with the expected Coverage data import. To accomplish this, two postman collections are provided. One for the API calls and another for the environment. They should have sample data setup in the requests already.

You'll need to use the Create Repository request and the Create bulk test coverage request once the server is running.

About

Simple front-end + back-end service for consuming, calculating, and displaying basic code coverage

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published