-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathtesting_the_impossible.txt
74 lines (55 loc) · 2.02 KB
/
testing_the_impossible.txt
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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
Testing the Impossible
Will be going through Copycopter client. What is that?
* write place holders in code where things are uploaded to copycopter
* anyone can edit from copycopter
* copycopter changes pushed back to app
Copyclient requirements (when they built it):
* automatic
* easy to setup
* cannot affect production performance
Copyclient features:
* 100% test driven
Don't mix concerns. Separation of Concerns:
* single responsibility principle: every object should have a single responsibility that is defined by its class.
* A responsibility is a reason for change.
* the more things you have to test, the harder, slower, and more confusing it becomes
Inherit Less:
* cannot test sub-class without testing super-class
Prefer composition to inheritance:
* things are not usually hierarchal
Don't Depend on Concretions:
* Dependency Inversion Principle: high level modules should not depend on low level modules
* dependency injection: wiki this to learn more
Avoid Soup
Create Seams:
* composed methods that support dependency injection
Testing Design:
* test scope:
* unit, component, isolation
* functional, acceptance, integration, full stack
* restrict fixture scope:
* use fresh fixtures - create what you need for test in the test
* avoid test helpers
* test doubles:
* stubs, mocks, proxies, and fakes
* USE FAKES:
* easier to be DRY, easier to be strict
* easy to distribute / share with others
Rails:
* stay generic:
* use middleware when possible
* avoid monkey patches
* keep business logic outside engine parts
* use Railties only for configuration/initialization
* integration test
* generate a rails app
* install your gem
* exercise major paths
* boot a server process if you need to
* test across several versions
* isolation tests:
* unit test components without Rails
* don't even load ActiveSupport
* test Rails-specific components separately
* use fakes
Don't be afraid