- Girl Code Intro by Ineke Scheffers - UI Testing & Libraries @ bloomon by Mariyana Nikolaeva - Unit testing using Mocha by Marie Treschow

1. @GirlCodeNL
/GirlCodeNL

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

3. @GirlCodeNL
/GirlCodeNL
Jest
Easy setup
Snapshot testing

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

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

6. 2strictly confidential -
• 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:

7. 3strictly confidential -
stack

8. 4strictly confidential -
applications
customer-
facing
backofficeAPI microservices

9. 5strictly confidential -
Inconsistent UI elements

10. 6strictly confidential -
the button(s)

11. 7strictly confidential -
possible solutions
bloomon UI

12. 8strictly confidential -
storybook

13. 9strictly confidential -

14. 10strictly confidential -
component library

15. 11strictly confidential -
• 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

16. 12strictly confidential -

17. 13strictly confidential -
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

18. 14strictly confidential -
• 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

19. 15strictly confidential -
Learnings

20. 16strictly confidential -
Do not fork big repositories

21. 17strictly confidential -
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

22. 18strictly confidential -
Thank you

23. Unit testing with
Mocha
npm install mocha -g
Marie Treschow

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

25. 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

26. 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

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

28. 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

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

30. Simple unit test
Terminal output

31. Testing your JavaScript
with Mocha, Chai and Sinon

32. 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

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

34. 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/

35. Simple async module

36. Asynchronous testing with Mocha
Terminal output

37. 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);
}

38. TDD style exampleBDD style example

39. Terminal output

40. 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

41. Hooks output example

42. 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’);

43. 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');

44. 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'});

45. 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

46. 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/

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