On 30/04/2014 16:43, Andrei Alexandrescu wrote:
Hello,
A coworker mentioned the idea that unittests could be run in parallel
(using e.g. a thread pool).
There has been a lot of disagreement in this discussion of whether
"unittests" blocks should run in parallel or not. Not everyone is
agreeing with Andrei's idea in the first place. I am another in such
position.
True, like Dicebot, Russel, and others mentioned, a Unit Test should be
a procedure with no side-effects (or side-effects independent from the
other Unit Tests), and as such, able to run in parallel. Otherwise they
are an Integration Test.
But before we continue the discussion, we are missing am more basic
assumption here: Do we want D to have a Unit-Testing facility, or a
Testing facility?? In other words, do we want to be able to write
automated tests that are Integration tests or just Unit tests? Because
if we go with this option of making D unittest blocks run in parallel,
we kill the option of them supporting Integration Tests. I don't think
this is good.
*Unit testing frameworks in other languages (JUnit for Java for
example), provide full support for Integration tests, despite the "Unit"
in their names. This is good. I think Integration tests are much more
common than in "real-world" applications than people give credit for.
Personally I find the distinction between Unit tests and Integrations
tests not very useful in practice. It is accurate, but not very useful.
In my mental model I don't make a distinction. I write a test that tests
a component, or part of a component. The component might be a low-level
component that depends on little or no other components - then I have a
Unit test. Or it might be a higher level component that depends on other
components (which might need to mocked in the test) - then I have an
Integration test. But they are not different enough that a different
framework should be necessary to write each of them.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
