blob: 812d2b81bae526e91d26544a8e2c3e925a60383f (
plain)
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
|
Design / Architecture of Test Repository
++++++++++++++++++++++++++++++++++++++++
Values
~~~~~~
Code reuse.
Focus on the project.
Do one thing well.
Goals
~~~~~
Achieve a Clean UI, responsive UI, small-tools approach. Simulataneously have
a small clean code base which is easily approachable.
Data model/storage
~~~~~~~~~~~~~~~~~~
testrepository stores subunit streams as subunit streams in .testrespository
with simple additional metadata. See the MANUAL for documentation on the
repository layout. The key design elements are that streams are stored
verbatim, and a testr managed stream called 'failing' is used to track the
current failures.
Code layout
~~~~~~~~~~~
One conceptual thing per module, packages for anything where multiple types
are expected (e.g. testrepository.commands, testrespository.ui).
Generic driver code should not trigger lots of imports: code dependencies
should be loaded when needed. For example, argument validation uses argument
types that each command can import, so the core code doesn't need to know about
all types.
The tests for the code in testrepository.foo.bar is in
testrepository.tests.foo.test_bar. Interface tests for testrepository.foo is
in testrepository.tests.test_foo.
External integration
~~~~~~~~~~~~~~~~~~~~
Test Repository command, ui, parsing etc objects should all be suitable for
reuse from other programs.
Threads/concurrency
~~~~~~~~~~~~~~~~~~~
In general using any public interface is fine, but keeping syncronisation
needs to a minimum for code readability.
|
