Matt Brown wrote: > Is it possible for you to refactor the TestSupport classes that the Model > unit tests depend on into a third artifact, which both projects (Model and > TestSupport) can then rely on (with scope=testing)? > That's essentially what I've been working on the last hour or so. So, now the dependency chain looks something like this:
Model -> TestSupport -> ModelTesting > As others have pointed out circular dependencies like this are a bad design. > I don't think of this as a circular dependency, because it's only a problem in the test scope. None of the core code exhibits any problem like this. It's simply caused by the convenience classes used for test purposes. > This might be hard to really say for sure without knowing what the Model code > looks like, but I would say that if the Model core code is so > convoluted/hard-to-use that you need to employ other objects just to build > and test them, then something is off with the design of the Model - and you > could probably re-design those classes to make a lot of things easier. > It's not so much a case of the classes being convoluted. When you get to higher levels, though, it becomes tedious to write test code without some helper classes. Example: - Customer has a collection of Sites. Site has a collection of Machines. Machine has a collection of Tasks. So, we use these Builder classes to create larger entities (Customer) without having to rewrite the code to fill in the collections every time we create a new test case. As a result, the Builder classes must rely on the Model, and the test cases for the Model rely on the Builders. Perhaps this is a bad design from some point of view. It sure is helpful, though. I'm always open to suggestions. Thanks for the input! Dave --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
