[TIP] What is a unit test (was: mocking a file in /proc)

[Ben Finney]

Gregory Salvan <apieum at gmail.com> writes:

> I feel confusion about what I've said.
> Let me be crystal clear: in the point of view of TDD *you never open a real
> file to test something in python* !

It's good that you acknowledge the confusion.

You are describing a style of test case: one where the unit to be tested
is isolated from external behaviour, such as the file system.

TDD is not a style of test, so you're not describing that. Rather, TDD
is a process the developer follows, to write the program and its tests.

The style of test is irrelevant to TDD. The confusion is easy to come
about because the proponents of TDD advocate *starting with* unit tests.
But nothing about the practice of TDD requires that the tests be unit
tests.

So “TDD” is the wrong term to use there.

What you describe above – isolating a specific unit of the program, such
as one function, for the duration of a test case – is special to unit
tests. So “unit test” is the term to use, if you want to avoid confusion.

> The common way to do this in [unit tests] is to use dependency
> injection and probably you'll see a strategy pattern emerging (or a
> partial one).

Yes, dependency injection is a good way to design a unit of code
<URL:https://en.wikipedia.org/wiki/Dependency_injection>, and it makes
software much simpler to comprehensively write unit tests for the code
unit.

-- 
 \        “Some people, when confronted with a problem, think ‘I know, |
  `\       I'll use regular expressions’. Now they have two problems.” |
_o__)                           —Jamie Zawinski, in alt.religion.emacs |
Ben Finney