around common test runners, mocking, and assertion libraries to facilitate more consistent writing of tests across projects. ▸ It allows tests to be written in the same way regardless of choice of test runner.
around common test runners, mocking, and assertion libraries to facilitate more consistent writing of tests across projects. ▸ It allows tests to be written in the same way regardless of choice of test runner. ▸ Tongue-in-cheek project (if you haven’t guessed it already) that has the potential to be quite useful.
project a developer might contribute to will have tests written in a slightly different manner to the last project they contributed to ▸ Which leads to the following conversation with yourself or pair partner:
project a developer might contribute to will have tests written in a slightly different manner to the last project they contributed to ▸ Which leads to the following conversation with yourself or pair partner: ▸ “Wait, which project is this? The one with Jasmine or Mocha?”
project a developer might contribute to will have tests written in a slightly different manner to the last project they contributed to ▸ Which leads to the following conversation with yourself or pair partner: ▸ “Wait, which project is this? The one with Jasmine or Mocha?” for a second
project a developer might contribute to will have tests written in a slightly different manner to the last project they contributed to ▸ Which leads to the following conversation with yourself or pair partner: ▸ “Wait, which project is this? The one with Jasmine or Mocha?” for a second ▸ “Mocha”
project a developer might contribute to will have tests written in a slightly different manner to the last project they contributed to ▸ Which leads to the following conversation with yourself or pair partner: ▸ “Wait, which project is this? The one with Jasmine or Mocha?” for a second ▸ “Mocha” for three seconds
project a developer might contribute to will have tests written in a slightly different manner to the last project they contributed to ▸ Which leads to the following conversation with yourself or pair partner: ▸ “Wait, which project is this? The one with Jasmine or Mocha?” for a second ▸ “Mocha” for three seconds ▸ “Ok, so that’s the should / better-assert / expect / unexpected / chai expect / chai assert / chai should / chai-sinon/ must assert syntax, right?
project a developer might contribute to will have tests written in a slightly different manner to the last project they contributed to ▸ Which leads to the following conversation with yourself or pair partner: ▸ “Wait, which project is this? The one with Jasmine or Mocha?” for a second ▸ “Mocha” for three seconds ▸ “Ok, so that’s the should / better-assert / expect / unexpected / chai expect / chai assert / chai should / chai-sinon/ must assert syntax, right? ▸ “Erm, I can’t remember. Just copy and paste from the existing tests”
uses an assertion syntax I’ve long forgotten is a PITA ▸ It’s an exercise in reading documentation and not writing tests. ▸ The tests I write now, using Hugs, will very likely be the same syntax in tests I write in 2 years time.
test: var test = require(‘tape'); var lib = require(‘..'); test(‘Array.indexOf()’,function (assert) { assert.plan(1); assert.equal([1,2,3].indexOf(4), -1, ’should return -1 when the value is not present’); }); var assert = require(‘assert'); describe('Array', function() { describe('#indexOf()', function() { it('should return -1 when the value is not present', function() { assert.equal(-1, [1,2,3].indexOf(4)); }); }); }); ▸ Mocha or Jasmine test:
One assert syntax. (Sinon and Chai asserts) ▸ A choice of test runners to allow for user preference. For example to choose on the basis of better tests reports or test speed.
One assert syntax. (Sinon and Chai asserts) ▸ A choice of test runners to allow for user preference. For example to choose on the basis of better tests reports or test speed. ▸ TDD not BDD i.e test() functions not describe() functions
One assert syntax. (Sinon and Chai asserts) ▸ A choice of test runners to allow for user preference. For example to choose on the basis of better tests reports or test speed. ▸ TDD not BDD i.e test() functions not describe() functions ▸ No nested test() functions. Nested test() functions are fashionable versions of callback pyramids. Flipflops vs sandals.
require('hugs'); // This example uses Mocha but the require call can be changed to 'tap' // and without any other changes, the tests will work const test = hugs(require('mocha')); const spy = test.spy; const assert = test.assert; let oUT = { method: () => { } }; test( 'a test with a spy', function (done) { // Note: no need to explicitly create a sandbox for spying. Sandbox creation is automatically taken care of. spy(oUT, 'method'); oUT.method(1, 2); assert.callCount(oUT.method, 1); assert.calledWith(oUT.method, 1, 2); done(); } ); > npm install hugs > mocha --recursive --ui tdd test/**/*.js
functions to execute after each test function ▸ assert - assertions object. Exposes Sinon and Chai assertions e.g test.assert.callCount(foo, 1)) ▸ beforeEach - Lifecycle method to register functions to execute before each test function ▸ chai - Chai object. ▸ createStubInstance - Sinon method for stubbing out constructors. ▸ done - ends the test for non Promise tests. Can be passed arguments of the test callback or a done argument if specified in the test signature. ▸ match - Sinon’s matcher api ▸ mock - Sinon mock (sandboxed for each test) ▸ only (Mocha) - Runs a single test test.only('a test', function(t){}); ▸ spy - Sinon spy (sandboxed for each test) ▸ stub - Sinon stub (sandboxed for each test) ▸ test - test method The test object returned from a hugs() call has the following API:
git clone [email protected]:lawrencec/hugs.git > cd hugs > npm install > cd hugs/examples > npm install > npm run help NPM - ls scripts --- example:ava - Run ava example example:browser - Run browser examples using jasmine and mocha example:browser:debug - Run browser example in karma debug mode. use HUGS_TEST_LIB=mocha| jasmine to specify test lib to use example:browser:dev - Run browser example in karma dev mode. use HUGS_TEST_LIB=mocha| jasmine to specify test lib to use example:browser:jasmine - Run browser examples using jasmine example:browser:mocha - Run browser examples using mocha example:mocha - Run mocha example example:tap - Run tap example examples - npm run example:ava; npm run example:mocha; npm run example:tap; help - List available npm run commands --- > npm run <select from above list>
kosmosebi
schroneko
izumin5210
sonatard
hanetsuki
faithandbrave
mizdra
seike460
sanfrecce_osaka
honnibal
demuyan
kishida
philnash
tmm1
vanstee
kneath
lara
soudai
jonrohan
ddemaree
morganepeng
marktimemedia
wjessup
philhawksworth
