unittest behaviour
Jonathan M Davis
newsgroup.d at jmdavisprog.com
Wed Dec 18 07:43:01 UTC 2024
On Tuesday, December 17, 2024 2:31:13 PM MST DLearner via Digitalmars-d-learn wrote:
> On Tuesday, 17 December 2024 at 19:56:32 UTC, H. S. Teoh wrote:
> [...]
> >
> > That means the compiler will have to rerun your program once
> > per unittest. That means your OS has to create a new process
> > per unittest. If you have a lot of unittests, that adds a huge
> > amount of overhead.
>
> Agreed, but only an issue when testing, not in production.
>
> [...]
>
> > It still does not solve the problem of unittests with
> > side-effects, like file or network I/O.
>
> To me, it is unreasonable to expect unittest (as a part of the
> compiler suite) to establish/reset those parts of the environment
> outside of the program source code (like creating/restoring test
> files etc).
> I regard that as something that is the programmer's
> responsibility [perhaps by writing a script that performs those
> tasks, and calling that script within the unittest].
Well, making sure that your tests don't rely on static state also ends up
falling under the programmer.
I can understand being frustrated in this particular situation, but to run a
separate process for every single unit test would slow down unit tests
_considerably_, and for many programmers, the common workflow involves
writing some code, running the tests, and then fixing the code all in quick
succession, and having that be slow can slow down development significantly.
So, running unittest blocks needs to be pretty fast so long as the code
being tested isn't slow.
And running the unittest blocks in separate processes would be for solving
an issue that most programs don't have, because most code does not have
static variables in the fashion that your example does. The vast majority of
code is written in a way that if you pass the same arguments to a function,
you'll get the same result. There are definitely counter-examples (e.g.
getting the time or using a random number generator), so obviously, it's not
always the case that a function returns the same result for the same
arguments, but when a program has a situation where it really does need to
have a function whose result is not going to always be the same for the same
arguments, then it's simply up to the programmer to figure out how best to
test it. It would be far too disruptive to tests in general to do otherwise.
Ultimately, D's unittest blocks are designed for the common case to make it
easy to add tests to your code. They don't have fancy features, and there
are going to be situations where they don't fit for on reason or another,
but they work quite well for the common case. You've just found an uncommon
case where they don't work as well, and for cases like that, you're
potentially going to need to do something else. What that something else is
will presumably depend on what exactly your actual code is doing. Often,
it's matter of refactoring your code so that the core logic can be tested
separately, but that really depends on what your code is doing.
- Jonathan M Davis
More information about the Digitalmars-d-learn
mailing list