Testing logic and interfaces
Automatically check that things are working as intended.
Tutorial
time | section | notes |
---|---|---|
00:00 | Intro | |
00:39 | Design | Rich Hickey's Simple Made Easy talk |
02:15 | Part 1: logic | |
02:39 | Add a function | |
09:12 | Simple library | OLSKHash |
10:50 | Complex library | Zero Data Wrap |
14:41 | Part 2: interface | |
15:58 | Add a link | OLSKGazette |
21:00 | Access | |
21:42 | Localize | |
22:39 | Misc | |
23:48 | Simple component | OLSKPlaceholder |
25:27 | URLs for each test | |
27:14 | Complex component | OLSKAppToolbar |
33:07 | Messages | |
37:33 | Concerns via files | |
38:36 | General tips | 'tests are your eyes' |
42:27 | Conclusion |
Part 1: logic tests (AKA unit tests)
Requires no build system and ideally runs unlimited tests in about one second. See Modular object structure for syntax.
Part 2: interface tests (AKA UI/integration tests)
Requires a server for [[System A]] and also building process for [[System B]]. See Build and run my apps on your machine for setup. Takes more time than logic tests and gets longer with more tests: optimizations welcome. Look for localizing in another video [[localizing (tba)]].
Technical note: runs Zombie headless, no concept of CSS or box model, just HTML and JavaScript.
Access
- is it on screen or not?
- decouple visibility from other concerns
Localize
- put the maximum on screen
- run suite for each supported language
- will fail or make noise about missing translations
- decouple language from other concerns
Misc
- can be for checking attributes, binding, sending messages, anything
- decouple configuration/behaviour from other concerns
General tips
Test as much as you can. If something is not testable because of the testing environment, write the test that should pass and then skip it. I avoid changing anything before writing tests.
'Tests are your eyes' (via Zura) – they are imperfect and should be distrusted at some level, but ignoring them entirely is like 'playing jenga with blackboxes'. Let the machine work for you.
Design for change. Assume that you have missed something and will need to adjust later. How easily can it be changed?
Part of Project workflow.