On 2014-05-06 19:58, Dicebot wrote:
These days I often find myself leaning towards writing mostly
integration tests with only limited amount of unit tests. But writing
good integration test is very different from writing good unit test and
usually implies quite lot of boilerplate. Truth is D does not currently
have any higher-level facility at all. It has an _awesome_ unit test
facility which gets often misused for writing sloppy integration tests.
I'd love to keep existing facility as-is and think about providing good
library augmentation for any sort of higher level approach.
Key property of D unit tests is how easy it is to add those inline to
existing project, unconstrained simplicity. In perfect world those are
closer to contracts than other types of tests. This provides good basic
sanity check for all modules you recursively import when run via `rdmd
-unittest`.
Good integration test is very different. It has certain assumptions
about initial system state and notifies user if those are not met. It
can take ages to run and can test real-world situations. It is not
supposed to be run implicitly and frequently. You don't want to keep
your integration tests inline because of amount of boilerplate code
those usually need.
I see no good in trying to unite those very different beasts and my
experience with existing test libraries has been very unpleasant in that
regard.
I don't see why would be bad to use "unittest" for integration tests,
except for the misguided name. It's perfectly to place "unittest" is
completely different modules and packages. They don't need to be placed
inline.
I see it as a code place to but code for testing. Then I don't have to
come up with awkward names for regular functions. It's also a good
palace since D doesn't allow to place statements and expression at
module level. Sure there's module constructors but I don't think that's
any better.
--
/Jacob Carlborg
