On 4/2/15 11:44 AM, H. S. Teoh via Digitalmars-d wrote:
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@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?
The way I see it, the notion of having one build with strippable
unittests is a nice idea but technically challenging. It's also low
impact - today concurrent CPU is cheap so running two concurrent
unrelated builds can be made as fast as one.
The simple effective step toward improvement is to uniformize the format
of assertion errors in unittests and to make it easy with tooling to
create unittest and non-unittest builds that are gated by the unittests
succeeding.
Andrei
