Developers Testing - Girl Code at bloomon

@GirlCodeNL
/GirlCodeNL
We are Girl Code
katja
ineke
@afkatja
@FYIneke

@GirlCodeNL
/GirlCodeNL
Jest
Easy setup
Snapshot testing

@GirlCodeNL
/GirlCodeNL
UI Testing & Libraries @ bloomon by Mariyana Nikolaeva
-- Break --
Unit testing using Mocha by Marie Treschow
Questions and discussion
Drinks
Program

1strictly confidential -
• tekst
• tekst
• tekst
Agenda
UI testing
and component libraries
bloomon & girl code 2018

• bloomon - stack and applications
• problem - many variations of the same component across apps
• solutions - storybook vs component library (e.g. material UI)
• summary - why consistency is important
In today’s talk:

stack

applications
customer-
facing
backofficeAPI microservices

Inconsistent UI elements

the button(s)

possible solutions
bloomon UI

storybook

component library

• fork material ui repository
• add bloomon components to as
submodule
• include material-ui as dependency in
package.json
• make imports from material-ui bloomon components
Approach

storybook
• quick to include in apps
• no build script required
• easy component preview
• no centralized components
• storybook addons not mature
enough
Pros and Cons
component library
• one repo for components
• easy to import in apps
• unified documentation
• overhead of build and run tools
• maintain repository or CDN
• complex task

• visual vocabulary between designers, UX and developers
• faster designs and implementation
• unified UIs and brand trust
• users learn how to use the UI faster
• less style micro decision to be made by developers
• single source of truth without code repetition
Why consistency is important

Learnings

Do not fork big repositories

Small, easy steps
• styles repository
• storybooks for components per app
• storybook repository (as submodules, npm package)
• UI tests - structural, interaction, style testing
• component library with unit, integration and visual regression
tests
• well documented and hosted styleguide website

Thank you

Unit testing with
Mocha
npm install mocha -g
Marie Treschow

Tonight’s Agenda
➔ Why testing?
➔ Testing levels
➔ Impact of good testing
➔ Unit Testing
➔ TDD vs BDD
➔ Mocha Framework
➔ Chai Assertion Library
➔ Sinon.js

Why Unit Testing?
“Adding value, not just bugs”
- Improve software quality
- Find bugs early
- Makes process agile
- Provides documentation
- Simplify debugging process
- Architecture
- Reduces cost

Different levels of software testing
Regression testing => previously developed software still performs
Acceptance testing => testing with respect to users needs
System testing => testing integrated system
Integration testing => individual units are combined
Unit testing => testing individual components

Business value of testing
★ Reliability
★ Customer satisfaction
★ Profitability
★ Shorter time to market

UNIT TESTING … where it all begins
What it is?
● Lowest level of software testing
● Individual units and components are tested
● Validate that each unit of code performs as designed
What it does?
➔ increase confidence in changing/maintaining code
➔ makes your code more reusable
➔ makes debugging easier
➔ code more reliable

What’s a good unit test?
1. Fast
2. Small
3. Simple
4. Plentiful
5. Isolated
6. Readable
7. Clean
What not to do...

Simple unit test
Terminal output

Testing your JavaScript
with Mocha, Chai and Sinon

Setting up
Mocha|Chai|Sinon
npm install mocha -g (OR) --save-dev
update your package.json and customize
your scripts in order to run mocha on
your terms, then simply run npm test
npm install chai --save-dev
npm install sinon --save-dev

Why Mocha?
★ Well maintained
★ Well documented
★ Optional assertion library
★ Supports TDD & BDD
★ Simplifies async testing
Let’s look at the features!

The power of Mocha
Features & Options:
● Browser support
● Async support, including
promises
● Test coverage reporting
● Hooks
● Test-specific timeouts
● Report test duration
● Highlights slow tests in
red and yellow
Useful flags:
- File watcher support
- Babel-hook
- Node debugger support
- Timeout
Psst.. check out:
https://mochajs.org/

Asynchronous testing with Mocha
Terminal output

TDD (test driven) vs. BDD (behavior driven)
1. Write the test
2. Run the test and see
it fail
3. Write the code
4. Run the test again
(not failing anymore)
5. Refactor
- More focused on the
features, not results
- Important: the ability
to read your tests like
a sentence is a
cognitive shift in how
you will think about it
Let’s imagine this function:
function factorial(n){
if(n < 0) return NaN;
if(n === 0) return 1;
return n * factorial(n-1);
}

TDD style exampleBDD style example

HOOKS
before();
runs before any tests in each describe() block
after();
runs after all tests in each describe() block
beforeEach();
runs before every test in a describe block
afterEach();
runs after every test in a describe block
Good for: setting up preconditions and clean up after your tests
(database fixture, servers etc)
Pieces of code run either before or after certain tests

Chai - should, expect, assert
● Pair with any JavaScript
testing framework
● Several interfaces that
allow you to choose
between whatever is
comfortable
Should (BDD)
Expect (BDD)
Assert (TDD)
expect('test').to.be.a('string');
[1,2,3].indexOf(4).should.equal(-1);
assert.strictEqual(true, true, ‘booleans are strictly equal’);

Assertion Methods
● equal
● strictEqual (===)
● deepEqual
● isNull
● include
● property
assert.deepEqual({ tea: 'green' }, { tea: 'green' });
assert.isNull(error, 'there was no error');
assert.include([1,2,3], 2, 'array contains value 2');
assert.property({ tea: { green: 'matcha' }}, 'property tea');

And some negative ones
● notEqual
● isNotOk
● notDeepEqual
● isNotNull
● notStrictEqual
assert.notEqual(3, 4, 'these numbers are not equal');
assert.isNotOk(false, 'this will pass');
assert.notDeepEqual({ tea: 'green'}, { tea: 'red'});

Sinon - spies, stubs, mocks
Things that makes testing hard:
➢ Databases
➢ Network
➢ File access
Spies/Stubs/Mocks: Test Doubles
➢ Replacements for pieces of code used in
your test

Different kinds of Test Doubles:
● Spies -> offer information about
function calls without affecting
their behavior
● Stubs -> are like spies, but
completely replace the function
(make it do whatever you like!)
● Mocks -> makes replacing whole
objects easy by combining both spies
and stubs (fake servers, timers,
xmlhttprequest)
http://sinonjs.org/

Testing TIPS:
➔ Keep your modules small
➔ Be sure to test success AND error
cases
➔ Test expected AND unexpected data
Thanks for listening!

Developers Testing - Girl Code at bloomon

Recommended

More Related Content

What's hot (20)

Similar to Developers Testing - Girl Code at bloomon (20)

More from Ineke Scheffers (8)

Recently uploaded (20)

Developers Testing - Girl Code at bloomon