Re: [Dunit-interest] Unit testing Delphi Bug List

[Michael A. J. <csm...@ho...>]

> > I am not entirely sure of this one. I think there would be
> > synchronization
> > problems, since presumably you'd need to include dunit in the
> > project into
> > this other project so that they would have the source so that
> > they could
> > modify and add tests.
>
> Currently at work, I keep a separate copy of the framework source checked
in
> with each separate project. I can't (at least couldn't in the early
stages)
> depend on the framework to stay 100% consistent with each new release. If
I
> come back to a project months later and want to run all the tests, I don't
> want to have to first update my unit tests with the latest framework -- I
> want it to run at 100% just as it did when I left it.

See this is where our testing style differs. We run all the unit tests every
night with the latest versions of the code checked out of our VCS.  If build
gets hosed because the test units won't compile, I consider that a problem
that needs fixing ASAP. Looking back a few months, I think this is why I
deep down fought against the change from assert to check because I knew what
it was going to do to my build. Now of course that the framework has matured
greatly and I really don't deal with this issue much as I do as why $#@!
didn't everything work last nite.

>
> So, yes, it's an issue - keeping a copy of DUnit in the [ProjectToBeNamed]
> sources, but I don't think it'll be a problem.
>
> Think about if/when we have 680-some tests running, then DUnit is changed
in
> some big or small way that affects some or all of the unit tests
(hopefully,
> that wouldn't happen, but ...), I wouldn't want the DUnit project burdened
> with the task of making sure all those tests get updated ... I think it
> should be separate.

I just see this as part of the XP challenge.  All tests must run 100% all
the time. IF the tests don't run (or compile) the code ain't done.