This repository is a microsite within the Vodafone Business Portal (VBP) for EWL.

👤 Who?

Team: Nordions

Product Owner: Martin Long

FE Team Lead: Steven Noakes

🚀 Getting Started

Prerequisites

• Node version >=14.17.1
• Yarn
• SSH access to Bastion
• Docker
• Have access to Vodafone private NPM package repository

Have a look at the set up guide for more help on the above.

Running locally

1. Clone the repository
2. Run yarn to install required dependencies
3. Run yarn nps start to build the site and run it with vite-dev-server

Where to go to see my page?

1. You need to change chrome settings first
2. Go here in chrome: chrome://flags/#allow-insecure-localhost
3. Enable first option, then restart chrome
4. Go to https://localhost:8000/fixed-line-quote/quote/ethernet-wireline
5. Advanced -> allow/continue

How to start in prod mode?

1. yarn nps to see options
2. Remember, prod mode runs on http not https

🥸 FakeDXL

We are using FakeDXL as our mocking solution for local development. It allows us to dynamically mimic the real JCS without connecting to live services. You can find more information on it here.

🤝 Contributing

Branching

Branch names must follow a specific pattern where they contain the Azure DevOps ID and a very short description of the change. The type of requirement i.e. story, bug, feature, etc should be at the start of the branch name as below.

• User Story - story/{id}-{description}
• Bug - bug/{id}-{description}
• Release - release/{id}-{description}

NB: Other than master, only branches that start with development/ or release/ can be independently deployed to an environment.

Versioning and Commiting

We are using commitlint to validate the commit messages and semantic-release to automate the changelog and version bumping.

• Commit message should be in the format "{type}: Normal commit message that will be displayed in the Changelog #{storyID}"

storyID: The ID the work item from Azure Devops, you can add multiple into your message

type: maps to a SEMVER which can be seen on release.config.js

NB: If you're still working on items and do not wish the commit message to appear in the changelog simply add WIP somewhere in the message. To force a major version you must include BREAKING CHANGE or BREAKING CHANGES in your commit message

Pull Requests

Once you have committed all your changes, a PR needs to be raised to get your changes merged into master. Pre-build checks have been enabled in the pipeline which will block a PR from being merged if it does not pass certain checks. It is recommended to ensure all checks are passing locally before creating a PR.

Pre-PR checks:

• No lint issues - run yarn nps lint
• All unit tests passing - run yarn nps test
• All Cypress tests passing
• No SonarQube issues

Creating a PR:

1. Create a PR here
2. Complete the PR checklist
3. Include a summary of the change
4. Include a screenshot of the change (if applicable)
5. Send the PR into the #nordions-public slack channel and ask for reviewers

🧪 Testing

For detailed information on Vodafones testing strategy, take a look at the Frontend Development Wiki.

Unit - Jest & React Testing Library (previously Enzyme)

Unit testing involves writing tests for each individual 'unit' of code, where a unit is the smallest testable part of any software. This usually means functions, classes or components and does not involve any writing to files, opening database connection or doing things over the network as this can be considered integration testing.

Jest is our test runner and is used for creating, running, and structuring tests.

React Testing Library provides utilities that help with testing React components. With it, we can render components, query components, and perform user interactions as a user would do if they were using the application.

Enzyme was used for unit testing before RTL was introduced, so you may still see it being used in older components. However, all new unit tests should using RTL.

Writing unit tests:

Instead of using RTLs render function, custom render function has been exported from @tools/unitTests/testing-library which should be used. This has exactly the same functionality but includes all the providers needed to render the component.

import { render } from '@tools/unitTests/testing-library'

test('has correct initial text', () => {
  const { getByText } = render(<Loader text='Loading...' />)
  expect(getByText('Loading...')).toBeInTheDocument()
})

Running unit tests:

• Run yarn nps test

Integration & E2E - Cypress

Cypress is an E2E testing framework, which allows us to perform tests and assertions against the site from a users perspective.

Running Cypress tests:

1. Run yarn nps start to build the site and run it with vite-dev-server
2. Run yarn cypress to start Cypress and load the test runner

Cypress tests are stored under cypress/integration and each spec.js is a separate test suite.

Static - SonarQube

As part of our ongoing initiative to improve code quality, Vodafone uses SonarQube to do static code analysis to scan our code for various code smells and possible re-factor opportunities.

Prerequisites:

• Run java --version to check if Java is installed on your system - if it is not you can download it here
• Run docker run -d --name sonarqube -p 9001:9000 sonarqube:latest to get the docker container

Getting started:

• Ensure the docker container is running and run yarn sonar
• Visit http://localhost:9000/

🏴‍☠️ Feature Flags

A feature flag is a software development process used to enable or disable functionality remotely without deploying code. New features can be deployed without making them visible to users. Read more about feature flags here.

LaunchDarkly is used for feature management within the application. LaunchDarkly's UI allows us to easily turn feature flags on and off for each environment we use.

Useful links:

• Signing up
• SSO log-in link

Development Vs Product Server

Where the flags value comes from depends on whether you're using the development or production server. Both servers use the /broadband/api/internal/features endpoint to expose the flags to the client. However, the production server reads the values from LaunchDarkly, whereas the development server defines these directly in development/routes/api/internal/index.ts. Advantages of this approach:

• Enables us to alter flags as we are developing without affecting lower environments
• Easier to manage in Cypress via the intercept method

Creating Feature Flags

Feature flags are created via a terraform script. To add a flag, you will need to PR in to dx-feature-flags-terraform. Flags should follow this template:

web-enterprise-ewl-{flag-name} = {
  project_key        = "vfuk-ebu"
  key                = "web-enterprise-ewl-{flag-name}-enable"
  name               = "Enable: {flag-description} [web-enterprise-ewl]"
  variation_type     = "boolean"
  tags               = ["Nordions", "web-enterprise-ewl"]
  include_in_snippet = true
},

Example PR

Receiving Feature Flags

Once the flag is created in LaunchDarkly, follow the steps below to make the flag available in the app.

1. Add friendly feature flag name and LaunchDarkly key in FeatureFlags enum in featureFlags.types.ts - the friendly flag name you set here is what will be available in the app
2. Set default flag value in featureFlags.ts - this will be used if the flag cannot be found in LD
3. Add the flag and it's desired value to the /feature endpoint on the development server - this will be used when developing locally

Using Feature Flags

The isFeaturesActive method on FeaturesService can be used to check the status of a feature flag. This class is a singleton which gets flags from /broadband/api/internal/features when the app is first rendered. Example usage:

import FeaturesService from '@shared/utils/FeaturesService'
import { FeatureFlags } from '@common/config/featureFlags'

FeaturesService.isFeatureActive(FeatureFlags.ewlJourneyEnabled)

⚠️ Known Gotchas

Coming soon...