Automatically check that things are working as intended.
|00:39||Design||Rich Hickey's Simple Made Easy talk|
|02:15||Part 1: logic|
|02:39||Add a function|
|10:50||Complex library||Zero Data Wrap|
|14:41||Part 2: interface|
|15:58||Add a link||OLSKGazette|
|25:27||URLs for each test|
|37:33||Concerns via files|
|38:36||General tips||'tests are your eyes'|
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)]].
- is it on screen or not?
- decouple visibility from other concerns
- put the maximum on screen
- run suite for each supported language
- will fail or make noise about missing translations
- decouple language from other concerns
- can be for checking attributes, binding, sending messages, anything
- decouple configuration/behaviour from other concerns
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.
Reply with a comment