unittests are really part of the build, not a special run

[H. S. Teoh via Digitalmars-d]

On Thu, Apr 02, 2015 at 11:19:32AM -0700, Jeremy Powers via Digitalmars-d wrote:
> On Wed, Apr 1, 2015 at 7:31 AM, Johannes Totz via Digitalmars-d <
> digitalmars-d at puremagic.com> wrote:
> 
> > On 31/03/2015 19:24, Andrei Alexandrescu wrote:
> > > Probably not; we're looking at two different builds. The build to
> > > be deployed has no unittest code at all.
> >
> > I'm starting to see this differently these days (basically since I
> > started to use jenkins for everything): A build you haven't unit
> > tested has implicitly failed. That means the release build that does
> > not have any unit test bits is not deployable.  Instead, compile as
> > usual (both debug and release), and run unit tests against both
> > (e.g. to catch compiler bugs in the optimiser).  Then for
> > deployment, drop/strip/remove/dont-package the unit test code.
> >
> >
> This.
> 
> I want to run unit tests as part of the build process, and I want my
> release build to have unit tests run against it.  If unit tests
> haven't passed for a build, it's not release ready.  But, I don't want
> my release build to be bloated with unit test code.
> 
> Related, unit tests often have dependencies that I _don't_ want as
> part of my release build.  Mocking frameworks are a good example.

So what do you want the compiler to do? Emit two executables, one
containing the release, the other containing the unittests? Isn't that
just a matter of running dmd with/without -unittest?


T

-- 
You have to expect the unexpected. -- RL