STONEm Client Update: Developing an Industry Standard Workflow.

Repository

https://github.com/stonecoinproject/stonem-frontend

On the debut post on STONEm client development, we added automated testing, static code analysis & strict linting to our development process to ensure good code quality assurance and minimize bugs on production. We also added Continuous Integration (CI) & Continuous Deployment strategies alongside a staging server for QA tests to our development road map.

What's New?

Continuous Integration (CI) was integrated into our development process with CircleCI & Code Climate. We also increased code test coverage levels to an all time high 98%.

Why Continuous Integration?

CircleCI runs all unit, end-to-end and functional tests upon successful pull request review and returns the build status. Our repository promptly rejects any pull request that leads to a failing build. This is pretty important as we are able to find breaking changes before they make their way into production.

Increasing code coverage levels is really an art and less of a science as code as code coverage checks four base criteria:

• Function coverage
• Statement coverage
• Branch coverage
• Condition coverage.

Core challenge has been increasing branch coverage to above 50% and we have been able to attain branch coverage levels of 61% by writing tests for if-else cases that execute if a value is trueor false. In the below test, we have a test that executes only when the isSelectedprop is true.

// src/__tests__/

test('A `Dot` element is rendered when the filter button is selected', () => {
    const {
        queryByTestId,
        unmount
    } = render(<FilterButton isSelected/>);

    const dot = queryByTestId('dot');
    expect(dot).toBeInstanceOf(HTMLElement);

    unmount();
})

To attain higher branch coverage levels, we must write a test that executes for the reverse condition.

test('No `Dot` element is rendered when the filter button is not selected', () => {
    const {
        queryByTestId,
        unmount
    } = render(<FilterButton isSelected={false}/>);

    const dot = queryByTestId('dot');    
    expect(dot).toBeNull();

    unmount();
})

Both tests execute the portion of code below.

Next, we are able to run further analysis to monitor code duplication, code coverage levels and code smells (poor coding practices) within our pulls with Code Climate. We ensure every pull request has a minimum code coverage level of about 70% and any pull request that drops overall code coverage levels below 70% provides a failing build.

Integrating Continuous Deployment.

Continuous deployment is really essential for a workflow with no friction. If we have to jump on the QA staging server for every time a pull is merged to the master, that'll really suck. We need to make sure a master merge automates the following:

• Recompilation of assets to source files.
• 3rd party code updates.
• Server restarts and/or reboots.

To do this, we use Git hooks to listen for master branch merges and sets off our automation shell script. This script restarts the server running with the pm2 NPM package.

cd /var/www/stonem-frontend

echo "Pulling from Master" 

git pull origin master

echo "Pulled successfully from master"

echo "Restarting server..."

pm2 restart server

echo "Server restarted Successfully"

We'd love to unveil our test server to the public but unfortunately that is not within the public domain now.

Roadmap

• Add capacity to create STONE masternodes directly from the interface.
• STONE wallet management all in one location.
• Better, more detailed Github & component documentation.

Commits

• fix lint errors & switch to types from interfaces.

• fix production bug where css prop is deprecated in favor of style

• Merge pull request #26 from creatrixity/fix/tslint-errors

Github Account

https://github.com/creatrixity