• Andrey Zherikov (12/12) Mar 29 2022 I have a function below (just an example). What's the recommended
• Steven Schveighoffer (19/32) Mar 29 2022 So keep in mind that versions are *module-wide*, and usually
• Andrey Zherikov (7/16) Mar 29 2022 Right, I can do per-version unit tests and the question becomes
• Steven Schveighoffer (4/22) Mar 29 2022 I don't think so. I think you need to run all the configurations one at
• Paul Backus (22/34) Mar 29 2022 Probably the easiest way is to split it into two functions
• Andrey Zherikov (23/44) Mar 30 2022 This is an option when you have big difference between foo and

Andrey Zherikov <andrey.zherikov gmail.com> writes:

I have a function below (just an example). What's the recommended 
way to unit-test it for all `version` cases?
```d
void f()
{
	import std.stdio: writeln;

     version(foo)
         writeln("foo");
     else
         writeln("no foo");
}
```

Steven Schveighoffer <schveiguy gmail.com> writes:

On 3/29/22 3:55 PM, Andrey Zherikov wrote:
 I have a function below (just an example). What's the recommended way to 
 unit-test it for all `version` cases?
 ```d
 void f()
 {
      import std.stdio: writeln;
 
      version(foo)
          writeln("foo");
      else
          writeln("no foo");
 }
 ```

So keep in mind that versions are *module-wide*, and usually 
*compilation-wide*. Which means that you won't be testing multiple 
version configurations in the same build.

First, it's hard to know how to properly solve this. Many version 
conditions either enable or disable a function, or they might make 
changes that shouldn't affect the outcome, but just utilize different 
mechanisms to accomplish the same result.

In the case where the version will enable or disable the whole function, 
you would enable the unittest based on that.

In the case where the version affects implementation details, you 
shouldn't change your unittest at all. Just compile it both ways, and it 
should work the same.

In the case where version is going to *affect the results of the 
function*, as yours does above, then what I would do is repeat the 
version tree as above, putting an individual unittest in each branch. 
But you could potentially do it inside the unittest itself. I just find 
that a bit convoluted.

-Steve

Andrey Zherikov <andrey.zherikov gmail.com> writes:

On Tuesday, 29 March 2022 at 20:20:46 UTC, Steven Schveighoffer 
wrote:
 So keep in mind that versions are *module-wide*, and usually 
 *compilation-wide*. Which means that you won't be testing 
 multiple version configurations in the same build.

 ...

 In the case where version is going to *affect the results of 
 the function*, as yours does above, then what I would do is 
 repeat the version tree as above, putting an individual 
 unittest in each branch. But you could potentially do it inside 
 the unittest itself. I just find that a bit convoluted.

Right, I can do per-version unit tests and the question becomes 
how to build&run all versions. Since I'm using dub, there is a 
way to express different versions through "configuration" specs 
in dub.json. Is there a way to tell `dub test` to test all 
configurations?

Steven Schveighoffer <schveiguy gmail.com> writes:

On 3/29/22 8:57 PM, Andrey Zherikov wrote:
 On Tuesday, 29 March 2022 at 20:20:46 UTC, Steven Schveighoffer wrote:
 So keep in mind that versions are *module-wide*, and usually 
 *compilation-wide*. Which means that you won't be testing multiple 
 version configurations in the same build.

 ...

 In the case where version is going to *affect the results of the 
 function*, as yours does above, then what I would do is repeat the 
 version tree as above, putting an individual unittest in each branch. 
 But you could potentially do it inside the unittest itself. I just 
 find that a bit convoluted.

 
 Right, I can do per-version unit tests and the question becomes how to 
 build&run all versions. Since I'm using dub, there is a way to express 
 different versions through "configuration" specs in dub.json. Is there a 
 way to tell `dub test` to test all configurations?
 

I don't think so. I think you need to run all the configurations one at 
a time.

-Steve

Paul Backus <snarwin gmail.com> writes:

On Tuesday, 29 March 2022 at 19:55:52 UTC, Andrey Zherikov wrote:
 I have a function below (just an example). What's the 
 recommended way to unit-test it for all `version` cases?
 ```d
 void f()
 {
 	import std.stdio: writeln;

     version(foo)
         writeln("foo");
     else
         writeln("no foo");
 }
 ```

Probably the easiest way is to split it into two functions

```d
void f()
{
     version (foo)
         fVersionFoo();
     else
         fDefault();
}

void fVersionFoo()
{
     /* ... */
}

void fDefault()
{
     /* ... */
}
```

Then you can write separate unit tests for both `fVersionFoo` and 
`fDefault`, and they will both be tested regardless of what 
settings you build with.

Andrey Zherikov <andrey.zherikov gmail.com> writes:

On Wednesday, 30 March 2022 at 04:15:24 UTC, Paul Backus wrote:
 Probably the easiest way is to split it into two functions

 ```d
 void f()
 {
     version (foo)
         fVersionFoo();
     else
         fDefault();
 }

 void fVersionFoo()
 {
     /* ... */
 }

 void fDefault()
 {
     /* ... */
 }
 ```

 Then you can write separate unit tests for both `fVersionFoo` 
 and `fDefault`, and they will both be tested regardless of what 
 settings you build with.

This is an option when you have big difference between foo and 
not-foo behavior. In my case they are 90% the same so I think 
I'll go this way:

```d
void fImpl(bool fooMode)()
{
     static if(fooMode)
         writeln("foo");
     else
         writeln("no foo");
}

version(foo)
     alias f = fImpl!true;
else
     alias f = fImpl!false;

unittest {
     // test fImpl!true
}
unittest {
     // test fImpl!false
}
```