Programming Testing: Isolation: Difference between revisions
No edit summary |
No edit summary |
||
Line 2: | Line 2: | ||
When designing for testing, you want to flatten out your call-stack.<br> | When designing for testing, you want to flatten out your call-stack.<br> | ||
Each method ideally can be used at the toplevel, with a fake, avoiding functions that call functions that call functions etc. | Each method ideally can be used at the toplevel, with a fake, avoiding functions that call functions that call functions etc.<br> | ||
Most of the time, this is achieved with interfaces. | |||
= Overrides = | = Overrides = |
Revision as of 16:09, 23 July 2022
This page is about writing code in a way that it can be tested in isolation (without collaborators).
When designing for testing, you want to flatten out your call-stack.
Each method ideally can be used at the toplevel, with a fake, avoiding functions that call functions that call functions etc.
Most of the time, this is achieved with interfaces.
Overrides
If possible in your language, you can override methods with a fake, or a mock.
Separating Produce/Modify
Separate creating/fetching info from mutating it.
This lets you test your mutations independently of collaborators with a variety of inputs.func GetHtml() string { // ... } func ModifyHtml(html string) string { // ... }Within parent callers, you can override these methods.
Abstract Side-Effects
The easiest way to do this is probably dependency inversion.
Bind a runner, executor, or library-interface you can sub in fakes for.