| |
 | Posted by Jonathan M Davis
in reply to DLearner |  Permalink Reply |
|
Jonathan M Davis 
Posted in reply to DLearner
| 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
|
