• Andrew Pennebaker (5/5) Dec 08 2018 I think it's lame to have to use magical code like
• Paul Backus (4/9) Dec 08 2018 The correct place to submit an enhancement request like this is
• Neia Neutuladh (11/15) Dec 08 2018 The original intent was for unittests to run before main(). Your debug /...
• Steven Schveighoffer (17/21) Dec 09 2018 This is in process of deprecation, but I dropped the ball on making sure...

Andrew Pennebaker <andrew.pennebaker gmail.com> writes:

I think it's lame to have to use magical code like 
`version(unittest) {} else` to guard our main functions, when we 
run unit tests. Could D go ahead and do the right thing, 
automatically shadowing our main functions when the unit tests 
are run?

Paul Backus <snarwin gmail.com> writes:

On Saturday, 8 December 2018 at 20:16:09 UTC, Andrew Pennebaker 
wrote:
 I think it's lame to have to use magical code like 
 `version(unittest) {} else` to guard our main functions, when 
 we run unit tests. Could D go ahead and do the right thing, 
 automatically shadowing our main functions when the unit tests 
 are run?

The correct place to submit an enhancement request like this is 
the D issue tracker at issues.dlang.org.

Neia Neutuladh <neia ikeran.org> writes:

On Sat, 08 Dec 2018 20:16:09 +0000, Andrew Pennebaker wrote:
 I think it's lame to have to use magical code like `version(unittest) {}
 else` to guard our main functions, when we run unit tests. Could D go
 ahead and do the right thing, automatically shadowing our main functions
 when the unit tests are run?

The original intent was for unittests to run before main(). Your debug / 
test builds always run the unittests. This is awkward because unittests 
might sometimes actually be heavier tests that talk to a database or write 
to local files or change global state that would be used in main().

The normal technique with dub is to put *only* main() in app.d. Sometimes 
I take that a step further: I put a runMain() function somewhere in my 
project, and app.d's main() just calls that. Dub automatically excludes 
app.d from the unittest build. Minimum possible code outside the tested 
zone.

Not necessarily awesome, but we do have workarounds.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 12/8/18 3:16 PM, Andrew Pennebaker wrote:
 I think it's lame to have to use magical code like `version(unittest) {} 
 else` to guard our main functions, when we run unit tests. Could D go 
 ahead and do the right thing, automatically shadowing our main functions 
 when the unit tests are run?

This is in process of deprecation, but I dropped the ball on making sure 
the deprecation happened in a timely manner (also I see the ddoc doesn't 
show the list very well...)

See this in the description of core.runtime.runModuleUnitTests: 
https://dlang.org/phobos/core_runtime.html#.runModuleUnitTests

"If the switch --DRT-testmode is passed to the executable, it can have 
one of 3 values:
1. "run-main": even if unit tests are run (and all pass), main is still 
run. This is currently the default.
2. "test-or-main": any unit tests present will cause the program to 
summarize the results and exit regardless of the result. This will be 
the default in 2.080.
3. "test-only", the runtime will always summarize and never run main, 
even if no tests are present."

Will do a PR to switch the default.

-Steve