forked from erichocean/blossom
/
TESTING
48 lines (36 loc) · 2.28 KB
/
TESTING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
SproutCore Unit Testing
ABOUT UNIT TESTS
Unit tests are divided into two types of tests: API unit tests and integration
tests. API unit tests test each public method and property to ensure that the
method behaves correctly according to its documentation. Integration tests
spot check the way various API methods are used together to ensure they
function correctly in usage scenarios.
Most unit tests found in the SproutCore framework are API unit tests.
Typically the testing directory for a framework will contain a folder
structure matching the framework source. Within those folders will be one
folder per source class file. Within that folder will be one test file per
method (or groups of methods of the methods are very closely related).
Integration tests, on the other hand, are all kept in the tests/integration
folder. Each file is named for the general type of integration scenarios
tested, but the structure and naming of this directory is less rigid.
WHERE TO ADD NEW UNIT TESTS
If you find a bug and reduce the problem down to a particular API method that
is not responding in the way you might expect, then the best place to add a
test for this is in the API unit tests. This will effectively make your unit
test part of the API "specification" that must be satisfied for all future
releases.
Often times, however, you will find bugs that are not due to a particular
method behaving badly but is due to a problem that occurs when you use a
series of API methods together in a certain way. For these kinds of tests
you should add a test to the integration directory. If one of the existing
files makes sense for your scenario, add it there. Otherwise, create a new
test file and add it there.
HOW TO WRITE API UNIT TESTS VS INTEGRATION
The purpose of an API unit test is to exercise individual methods in the API
in isolation of the rest of the API. You should swap out methods, mock
objects, or make any other temporary modifications to the framework needed to
make the method run as isolated as possible from other methods.
Integration tests, on the other hand, are about testing API usage in place.
Avoid mocking parts of the framework unless necessary. Try to run the
framework code in its natural state to ensure the full stack is exercised just
as it would be in production code.