Please consider:

size_t foo() {
   static size_t var1 = 1;

   var1 = var1 + 1;
   return var1;
}

unittest {

   assert(foo() == 2);
   assert(foo() == 3);
}

which works as expected.

But

size_t foo1() {
   static size_t var1 = 1;

   var1 = var1 + 1;
   return var1;
}

unittest {
   assert(foo1() == 2);
}

unittest {
   assert(foo1() == 2);
}

Fails on the second unittest.

I appreciate this behaviour matches the docs (so not a bug), but is it desirable?

To me, as a test harness, a umittest block should be a completely fresh-from-scratch invocation of the code inside the block, and thus not depend on the result/effects of any previous unittest.

On Sunday, 15 December 2024 at 08:45:22 UTC, DLearner wrote:

yes, the alternative would be that unittests attempt to undo themselves, and that would make bugs horrible horrible bugs or executable clear global scope and stack effectively restarting the program, this could be incredibly slow if you have big arrays in global scope and then hundards of small unrelated unittests(which btw you do, the std has plenty and I think the run time also injects some)

On Sunday, 15 December 2024 at 08:45:22 UTC, DLearner wrote:

size_t foo() {
   static size_t var1 = 1;

   var1 = var1 + 1;
   return var1;
}

unittest {

   assert(foo() == 2);
   assert(foo() == 3);
}

size_t foo1() {
   static size_t var1 = 1;

   var1 = var1 + 1;
   return var1;
}

unittest {
   assert(foo1() == 2);
}

unittest {
   assert(foo1() == 2);
}

Yes. Remember that you have the function attribute pure [1]. It would have avoided the problem.. for instance:

size_t foo1() {
   static size_t var1 = 1;

   var1 = var1 + 1;
   return var1;
}

pure unittest {
   assert(foo1() == 2);
}

pure unittest {
   assert(foo1() == 2);
}

refuses to compile with the following errors

With pure that you would have seen the problem, that is "oh, the global state".

On Sunday, 15 December 2024 at 20:30:21 UTC, monkyyy wrote:

What is wrong with changing the specification of unittest so that it recompiles/reexecutes the associated source on every unittest {} block?

That way, there would be no alteration in behaviour if the source was 'pure', but you would have flexibility if you wanted to test source that was (intentionally) 'stateful'.

On Tuesday, 17 December 2024 at 19:56:32 UTC, H. S. Teoh wrote:
[...]

Agreed, but only an issue when testing, not in production.

[...]

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].

On Tuesday, 17 December 2024 at 21:31:13 UTC, DLearner wrote:

testing is where compile times matter

Only need to ship code once, ideally I compile code every few seconds

On Tuesday, 17 December 2024 at 19:16:55 UTC, DLearner wrote:

Sounds also slow