Hi Steve,
thanks a lot for sharing your experiences.
Steve Ebersole:
> In my opinion it really all comes down to how confident are you that your
> changes did not cause regressions when you build that module/project (with
> its
> tests executed). Relying on the execution of an external module/project for
> that confidence is a recipe for problems in my experience.
The idea would be that executing the tests would not be any different.
Same gradle call, same dependencies.
> We've struggled with this back and forth in Hibernate because most of our
> tests are more the functional variety; we have very few unit tests. For
> numerous reasons we tried moving the test suite into a separate module as you
> suggest. In my experience that caused a lot of problems where developers
> would not even run the test suite, so be careful.
Well, as a line of last defense, the tests are executed on the build server
with every commit anyway.
Whoever forgets to run the tests locally and breaks the build will
feel the peer pressure :-)
As a side note: in the early days of XP when we had this discussion, I was
known as the one who proposed an extreme version of _your_ position :-)
with Tests in same source dir as production code and if possible even
in the same file!
This was all to make sure that devs are always aware of the tests.
However, today this has become obsolete since any decent IDE has
a package view that shows production code and their tests
side-by-side not matter what the physical locations are.
Anyway, thanks for your insights and keep gradling Hibernate!
Dierk
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
