The most popular online DAWs and virtual instruments are plagued with advertisements and a lack of key features required by musicians. Our virtual piano is the start of an idea to revolutionise the creation of music and beautiful melodies, all from your browser. Here are some of the key features we are aiming to bring to the table:
- A tuneful and rich Piano sample
- Being able to play using your keyboard!
- Volume control
- Key visualisation
- Built-in configurable metronome
The team used GitHub's Project Tracker for project management to manage issues and use the kanban methodology and maintain a workflow where we could continuously improve, visualise our workflow on a regular basis and sort tasks in order of priority.
This project requires npm to execute the files, so ensure that it is installed.
node -vnpm -vIf they are not installed, follow the steps on npm Docs.
npm install -g serveIf you are getting some errors after using that command and you are on Linux/MacOS, try running it as a superuser (sudo)
git clone https://github.com/adaapp/testing-dec2021-team3.gitNow, you should have everything that you need to proceed! Navigate into the folder you just cloned to find our code :)
npm installIf you get some vulnerability warnings after executing this command, don't worry ;), it's the React team that has to do some catch-up...
npm startRuns the app in the development mode. 👆
Open http://localhost:3000 to view it in your browser.
The page will reload when you make changes.
You may also see any lint errors in the console.
npm testaThis launches the test runner in the interactive watch mode. 👆
Clicking on the 'a' key runs all tests (excluding End-to-End tests).
See the section about running tests for more information.
npm test -- --coverage --watchAll=falsenpm run buildBuilds the app for production to the build folder. 👆
It correctly bundles React in production mode and optimizes the build for the best performance.
See the section about deployment for more information.
PORT=4571 serve -s build & npm run test:e2e'PORT=4571' is used to set the port where the production server will be listening for incoming connections. We decided to use a very specific number so that it doesn't interfere with any of your servers <3 (especially if you are testing multiple apps for some scholar reason?)
We are big on testing, so we're using Puppeteer to automate our end to end testing! Puppeteer requires a running production server to test our awesome app. If the commands above do not work for you, please feel free to raise an issue :).
$ npm run ejectNote: this 👆 is a one-way operation. Once you eject, you can't go back!
If you aren't satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.
Instead, it will copy all the configuration files and the transitive dependencies (webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you're on your own.
You don't have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn't feel obligated to use this feature. However we understand that this tool wouldn't be useful if you couldn't customize it when you are ready for it.
Throughout this project we ensured that the code is easily readable, whilst still maintaining the correct naming conventions; by using the camelCase practice throughout the entire code, and while still making sure that that all lines are correctly indented, ensuring that any other programmer could still read and understand the code. Furthermore, the code also has comments on every line of code to ensure that anyone can understand what is happening at every step of the code. The team also made sure the code had the correct indentatiouts throughout the entire code.
In order to begin our project, we began conceptualising the design of our virtual keyboard in Figma. Figma is a cloud-based design tool that provides real-time and simultaneous collaboration which is essential for our team of 5. This meant that during our initial designs where we all created a design, we were all able to transparently see and adjust each other's interpretation of a virtual keyboard and mélodie's theme. We then collaborated on a Google meeting on the best features, colours, layouts and structured of each team members design and in the end, we formalised our preferances into 2 designs.
| Design 1 | Design 2 |
|---|---|
 |
 |
Before coming down to 2 designs, multiple figma designes were used to ensure that we came to the best conclusion when choosing the final design.
Click here for our Figma document.
Additionally, click here for our Figma Prototype.
The team used regression testing to maintain code base consistency. Regression testing creates a snapshot of the DOM (HTML) for each of the components, if any of those components change it will throw an error if not the test will pass.
The react testing library is used for testing the UI in units. This is because react testing library is a set of helper functions that allow us to test React components without relying on their implementation details.
For testing the logic of the website we used react testing library's Jest. Jest (standalone) is utilised to test the logic of the application, this is because Jest is an javascript testing framework designed with simplicity in mind and Jest supports projects coded using Babel, Typescript, Node, React, Angular, Vue and more; Making Jest an ideal testing framework for our project. Using Jest, the team worked together to produce testing blocks that lead to 90-100% code coverage within a short period of time. Using Jest is beneficial for this project because unit testing using Jest allows us to make our project more agile as we are already confident that the code we have will not break easily as we've found and prevented bugs earlier in the development cycle.
Coveralls is a web service that allows us to track the code coverage of our digital piano website over time in order to optimize the effectiveness of our unit tests. Coveralls also assist the team in making sure that all of the code is well tested and it allows the team to check the code coverage over time. Coveralls does this by collecting code coverage data and analyses it for issues that the user normally wouldn't find until there some sort of an error. Coveralls will produce a summary of this data in a simplified interface where you can see the trends and changes for coverage on all of the source files used.
Coveralls also gives the user a badge that has been added to the readme to provide up-to-date information about our coverage status from viewable github. We don't want to flex, but look at that beautiful green badge:
Puppeteer is a Node library which provides a high-level API to control Chrome or Chromium over the DevTools Protocol, the team used Puppeteer to automate End-to-End testing. We have also integrated React E2E Testing with Puppeteer into a GitHub action, allowing us to test our code with Puppeteer whenever we push or make a pull request :)
In order to decide out of the 2 designs which is the most suitable, we agreed to implement A/B testing. This is a method of comparing an original and alternative version of a webpage or webpage element against each other to determine which one performs better and is more aligned with the project objectives or themes. Usually, this is measured through conversion rates, however, we decided to ask users from our cohort as well as work colleagues which design they liked the most and to provide any additional feedback. The additional feedback is crucial to ensure that the design and functionality are well-suited and comfortable for the end-users. We did this through a Google Form 
and the results of the form demonstrate that Design 2 has had more success which means that as a team, we will work towards achieving this design in the final product.
 |
 |
Whilst gathering any feedback from the previous form and discussions and incorporating it into the final product, we decided to construct a Google Form that would test the usability of the final product's design. Usability testing is a technique to evaluate a device or product, such as a web form or webpage. By testing our product on real users, we were able to identify issues regarding navigation, accessibility as wells as problems that automated tools may not find as well. Those issues can then be translated into Github issues which as a team, we can later resolve. Here are the results:
 |
 |
 |
 |
In order to improve the quality of our webpage, we used the Google Lighthouse tool to generate a report containing a summary of the quality of our application. Lighthouse is a free and open-source tool that can be accessed through the development console for Chromium-based browsers. In order to improve the quality of our webpage, we used the Google Lighthouse tool to generate a report containing a summary of the quality of our application. Lighthouse is a free and open-source tool that can be accessed through the development console for Chromium-based browsers. There are 4 metrics which we have focussed on which were:
- Performance which is an aggregation of how the page progressed in aspects such as loading speed, time taken for loading basic frames and displaying meaningful content.
- Accessibility which is an aggregation of how accessible the website is through audio captions, button names and 'aria-' attributes.
- Best Practices which is an aggregation of many practices that have been deemed 'best' such as use of HTTPS and avoiding the use of deprecated code.
- SEO which is an aggregation of scores in features such as meta description, presence of titles, legible font sizes.
The websites performance rating of 99 suggests it's highly optimised and as a result, the website will offer a streamlined and smoother experience giving the user a better experience as a whole when using our website, it also decreases the bounce rate of users who attempt to access the website incase it takes too long to load. Poor performance hurts the overall user experience and offers less incentive to stay.
The accessibility rating of 82 improves our search engine optimisation results and makes it easier for each user to use the website regardless of age. The website's design also includes contrasting colours with the use of black and white keys for the piano which is the most important feature that users should be able to interact with.
The best practices rating of 100 suggests that the websites design is simple and easy to navigate.
The search engine optimisation (SEO) rating of 100 is suggests the websites design attracts higher quality internet traffic and traffic will be directed to the website naturally without having to advertise it.
For the full document click here .
Manual testing was completed on the mélodie website and documented using google docs. The purpose of Manual Testing in for this is to identify any bugs, issues, or defects in the website. Manual software testing helps to find critical bugs in the website design such as features not working as intended or not working at all. This allows us to Debug the website and improve features which did not have necessary code implemented to fix specific bugs which may occur when the user is using our digital piano. Although Manual website Testing requires more effort our team realised it was imperative to check automation feasibility; Additionally, Manual Testing concepts do not require knowledge of any testing tool.
This is an example of an issue which was discovered while manually testing the design. This was caused by first, not playing any keys and second adjusting the volume slider. This was fixed using the exposed howl data object and setting the volume to Howl directly, allowing the test to pass.
Netlify is used to continuously deploy our changes, every time we push to the main branch, the website goes live with a new version, when a pull request is made in our workflow, netflify also checks if there are any warnings, and makes a preview for that specific pull request. This is beneficial for our team because netlify is incredibly quick and easy to use for getting started with our website, saving time and increasing productivity as a result. Netlify will also save more time as you can lock onto a main branch for main deployments. It can also deploy other branches and give you a URL to test those deploys, improving the amount of time it takes for you test your code before merging it to your main; Also giving you an easier option to manually test other branches.
GitHub Actions is used to automate the testing pipeline every time code is pushed or a request is made. This allows the team to create workflows that build and test every pull request to the repository, or deploy our merged pull requests to production. The team is also using GitHub Actions to improve the workflow of the team by automatically adding the appropriate labels.
For additional examples of GitHub Actions click here
You can learn more in the Create React App documentation.
To learn React, check out the React documentation.
This section has moved here: https://facebook.github.io/create-react-app/docs/code-splitting
This section has moved here: https://facebook.github.io/create-react-app/docs/analyzing-the-bundle-size
This section has moved here: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app
This section has moved here: https://facebook.github.io/create-react-app/docs/advanced-configuration
This section has moved here: https://facebook.github.io/create-react-app/docs/deployment
This section has moved here: https://facebook.github.io/create-react-app/docs/troubleshooting#npm-run-build-fails-to-minify