part 1
communicate using a common language
"filarmonica"
System Under Test
a statement that is always expected to be true
// "TDD-style" assertTrue(x > 0);
// "BDD-style" expect(x).toBeGreaterThan(0);
expect(x > 0).toTruthy();
a set of statements that verify a single use-case scenario
// typical test structure, the 4 As it("should set()", function() { // 1. arrange (fixtures) sut.init();
// 2. act (run tested unit)
sut.set(2);
// 3. assert (only 1 logical)
expect( sut.get() ).toEqual(2);
// 4. annihilate (reset state)
sut.destroy();
});
// async test it("should set async", function(done) { doAsyncRequest().then(function(data) { // assert done(); });
});
// resume execution first it("should set async", function(done) { doAsyncRequest().then(function(data) { done(); // assert });
});
a set of tests that completely verify a single use-case
// test suite in Jasmine describe("suite name", function() { it("should get", function() { // ... });
it("should set", function() {
// ...
});
});
a set of actions required to run all tests in the suite
arrange fixtures
// setup in Jasmine describe("suite name", function() { beforeEach(function() { // setup code });
});
a set of actions needed to bring the SUT to it's initial state
// teardown in Jasmine describe("suite name", function() { afterEach(function() { // teardown code });
});
a context needed for the tests
HTML markup, Objects, Database, files
objects that mimic real behavior
xUnit Test Patterns
Test Double
|
|
Dummy
|
|
Spy
|
|
Mock
\
\
\
\
Fake
|
|
Stub
a report on what parts of the SUT were called during the tests
it does not show the amount of tested code
high coverage "could" mean "good tested code", but also could be misleading, low coverage always means "not enough"
software metric,
number of pathways through code
// low CCN: 2
function foo(arr) {
var indexArr = [],
min;
arr.forEach(function(item) {
var stat = item.status,
index = statusArray.indexOf(stat);
indexArr.push(index);
});
min = Math.min.apply(this, indexArr);
return statusArray[min];
}
// high CCN: 4
function foo(x, y) {
return (x && y) ? "both" : "some";
}
testing type
interested in the internal structure of the SUT
written mostly by developers,
unit, integration
testing type
interested only in the I/O of the SUT,
not in the internal structure
written mostly by testers,
e2e, API ?!