On Wednesday, 18 December 2024 at 07:43:01 UTC, Jonathan M Davis
wrote:
[...]
- Jonathan M Davis
Thinking about this a little more:
Suggestion:
Leave the current behaviour as default, but introduce an option
(-r ?) so that
```
unittest -r {
}
```
forces a complete rebuild
(for clarity, i
On Tuesday, 17 December 2024 at 21:31:13 UTC, DLearner wrote:
[... environmental requirements]
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].
This holds for the requirment
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
> >
On Tuesday, 17 December 2024 at 19:16:55 UTC, DLearner wrote:
On Sunday, 15 December 2024 at 20:30:21 UTC, monkyyy wrote:
On Sunday, 15 December 2024 at 08:45:22 UTC, DLearner wrote:
I appreciate this behaviour matches the docs (so not a bug),
but is it desirable?
yes, the alternative would
On Tuesday, 17 December 2024 at 21:31:13 UTC, DLearner 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 uni
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 onl
On Tue, Dec 17, 2024 at 07:16:55PM +, DLearner via Digitalmars-d-learn
wrote:
[...]
> What is wrong with changing the specification of unittest so that it
> recompiles/reexecutes the associated source on every unittest {}
> block?
That means the compiler will have to rerun your program once p
On Sunday, 15 December 2024 at 20:30:21 UTC, monkyyy wrote:
On Sunday, 15 December 2024 at 08:45:22 UTC, DLearner wrote:
I appreciate this behaviour matches the docs (so not a bug),
but is it desirable?
yes, the alternative would be that unittests attempt to undo
themselves, and that would
On Sunday, 15 December 2024 at 08:45:22 UTC, DLearner wrote:
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_
On Sunday, 15 December 2024 at 08:45:22 UTC, DLearner wrote:
I appreciate this behaviour matches the docs (so not a bug),
but is it desirable?
yes, the alternative would be that unittests attempt to undo
themselves, and that would make bugs horrible horrible bugs or
executable clear global
On Sun, Dec 15, 2024 at 08:45:22AM +, DLearner via Digitalmars-d-learn
wrote:
[...]
> 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 th
11 matches
Mail list logo
