Re: Quandary over testing support classes.
Barrie Treloar wrote: I think I see what you are saying. Model (test) depends upon Test Support (main and test jars) I am going to assume that Test Support does not depend upon Model (either main or test) Almost, but not quite. TestSupport does depend on Model, because it includes the Builder classes that create Model objects for unit and functional tests. It just works out that some of the more complex unit tests for Model classes *also* use the builders. So, Model must be built before TestSupport, and TestSupport depends on Model. I just have these few unit tests that really belong in the Model module but are currently in the TestSupport module because of their dependencies on the builders. I've only been able to see a few ways out of this: 1) Move business logic out of the Model and into some intermediate module. (This moves me away from an OO paradigm. IMO) 2) Rewrite my Model unit tests so that they don't use builders. (This makes the tests less readable/maintainable.) 3) Create a new module that is nothing more than just the unit tests on the Model module. Then dependencies can be resolved pretty easily. 4) Keep it as I have it now, with a few special Model unit tests living in the TestSupport module. (I don't like this. I think it will cause confusion in the future.) I just figured that I couldn't possibly be the first person to run into this problem. So, I was curious how others resolved it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Quandary over testing support classes.
Barrie Treloar wrote: I think I see what you are saying. Model (test) depends upon Test Support (main and test jars) I am going to assume that Test Support does not depend upon Model (either main or test) Almost, but not quite. TestSupport does depend on Model, because it includes the Builder classes that create Model objects for unit and functional tests. It just works out that some of the more complex unit tests for Model classes *also* use the builders. So, Model must be built before TestSupport, and TestSupport depends on Model. I just have these few unit tests that really belong in the Model module but are currently in the TestSupport module because of their dependencies on the builders. I've only been able to see a few ways out of this: 1) Move business logic out of the Model and into some intermediate module. (This moves me away from an OO paradigm. IMO) 2) Rewrite my Model unit tests so that they don't use builders. (This makes the tests less readable/maintainable.) 3) Create a new module that is nothing more than just the unit tests on the Model module. Then dependencies can be resolved pretty easily. 4) Keep it as I have it now, with a few special Model unit tests living in the TestSupport module. (I don't like this. I think it will cause confusion in the future.) I just figured that I couldn't possibly be the first person to run into this problem. So, I was curious how others resolved it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Quandary over testing support classes.
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)? As others have pointed out circular dependencies like this are a bad design. 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. -Original Message- From: David C. Hicks [mailto:dhi...@i-hicks.org] Sent: Tuesday, June 16, 2009 12:17 PM To: Maven Users List Subject: Re: Quandary over testing support classes. Barrie Treloar wrote: I think I see what you are saying. Model (test) depends upon Test Support (main and test jars) I am going to assume that Test Support does not depend upon Model (either main or test) Almost, but not quite. TestSupport does depend on Model, because it includes the Builder classes that create Model objects for unit and functional tests. It just works out that some of the more complex unit tests for Model classes *also* use the builders. So, Model must be built before TestSupport, and TestSupport depends on Model. I just have these few unit tests that really belong in the Model module but are currently in the TestSupport module because of their dependencies on the builders. I've only been able to see a few ways out of this: 1) Move business logic out of the Model and into some intermediate module. (This moves me away from an OO paradigm. IMO) 2) Rewrite my Model unit tests so that they don't use builders. (This makes the tests less readable/maintainable.) 3) Create a new module that is nothing more than just the unit tests on the Model module. Then dependencies can be resolved pretty easily. 4) Keep it as I have it now, with a few special Model unit tests living in the TestSupport module. (I don't like this. I think it will cause confusion in the future.) I just figured that I couldn't possibly be the first person to run into this problem. So, I was curious how others resolved it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Quandary over testing support classes.
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. But I do, absolutely, agree with your statement - circular dependencies in the core code are bad. 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
Re: Quandary over testing support classes.
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
Re: Quandary over testing support classes.
On Wed, Jun 17, 2009 at 1:46 AM, David C. Hicksdhi...@i-hicks.org wrote: Barrie Treloar wrote: I think I see what you are saying. Model (test) depends upon Test Support (main and test jars) I am going to assume that Test Support does not depend upon Model (either main or test) Almost, but not quite. TestSupport does depend on Model, because it includes the Builder classes that create Model objects for unit and functional tests. It just works out that some of the more complex unit tests for Model classes *also* use the builders. So, Model must be built before TestSupport, and TestSupport depends on Model. I just have these few unit tests that really belong in the Model module but are currently in the TestSupport module because of their dependencies on the builders. I've only been able to see a few ways out of this: 1) Move business logic out of the Model and into some intermediate module. (This moves me away from an OO paradigm. IMO) 2) Rewrite my Model unit tests so that they don't use builders. (This makes the tests less readable/maintainable.) 3) Create a new module that is nothing more than just the unit tests on the Model module. Then dependencies can be resolved pretty easily. 4) Keep it as I have it now, with a few special Model unit tests living in the TestSupport module. (I don't like this. I think it will cause confusion in the future.) I just figured that I couldn't possibly be the first person to run into this problem. So, I was curious how others resolved it. You have a cyclic dependency. The solution is to break the cycle. There isn't another way. Your choices on breaking it are: * Move TestSupport into Model (not ideal) * Move the code in Model that TestSupport relies upon into its own module. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Quandary over testing support classes.
Barrie Treloar wrote: You have a cyclic dependency. The solution is to break the cycle. There isn't another way. Your choices on breaking it are: * Move TestSupport into Model (not ideal) * Move the code in Model that TestSupport relies upon into its own module. Yeah, that's what I figured the answer would be, and I've already implemented the 2nd option you mentioned here. It was worth a shot to see if anyone had any other solutions, though. Thanks for all the input! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Quandary over testing support classes.
Hi gang, I've been trying to find a reasonable solution to a problem we have with our Maven-based project. We have a collection of Builder classes that can create Model objects for testing purposes. These are segregated into a separate module (TestSupport) which has the Model artifact as a dependency. This works great for almost everything. The catch is that the more complex Model classes have unit tests that rely on these builders to make the test code easier to read and maintain. So, in that case the Model artifact would need to have the TestSupport artifact as a dependency. Obviously, this isn't going to fly. For the time being, the more complicated unit tests are being held in the TestSupport module, but this really isn't where they belong. We need to keep the Builders in an artifact of their own because they are used by other modules for unit and functional tests. I can see an argument that I might hear, that the Model classes should be simple beans - DTO's, if you will - that have no real need for unit tests. That's a step away from OO, though, isn't it? Maybe we're trying too hard to be as OO as possible? I really don't like the idea of stripping a class of its behavior. On the other hand, maybe there's a better way to get my Maven build set up that will solve this problem for me. Any help? Thanks, Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Quandary over testing support classes.
On Tue, Jun 16, 2009 at 11:01 AM, David C. Hicksdhi...@i-hicks.org wrote: Hi gang, I've been trying to find a reasonable solution to a problem we have with our Maven-based project. We have a collection of Builder classes that can create Model objects for testing purposes. These are segregated into a separate module (TestSupport) which has the Model artifact as a dependency. This works great for almost everything. The catch is that the more complex Model classes have unit tests that rely on these builders to make the test code easier to read and maintain. So, in that case the Model artifact would need to have the TestSupport artifact as a dependency. Obviously, this isn't going to fly. For the time being, The main code depending on test code is bad design. Pull out the pieces of the code from the test directories and promote it to main code. You should be able to untangle just enough for the main code to no longer depend on test. the more complicated unit tests are being held in the TestSupport module, but this really isn't where they belong. We need to keep the Builders in an artifact of their own because they are used by other modules for unit and functional tests. [del] On the other hand, maybe there's a better way to get my Maven build set up that will solve this problem for me. Either pull out the pieces and place into src/main/java as suggested above, or create another module that can contain the helper/build methods and have your main code depend on the helper artifacts. Using another module will mean that those helper classes are already built and available for your use. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Quandary over testing support classes.
I think my original message may not have been clear. I've tried to clarify it below. Barrie Treloar wrote: On Tue, Jun 16, 2009 at 11:01 AM, David C. Hicksdhi...@i-hicks.org wrote: Hi gang, I've been trying to find a reasonable solution to a problem we have with our Maven-based project. We have a collection of Builder classes that can create Model objects for testing purposes. These are segregated into a separate module (TestSupport) which has the Model artifact as a dependency. This works great for almost everything. The catch is that the more complex Model classes have unit tests that rely on these builders to make the test code easier to read and maintain. So, in that case the Model artifact would need to have the TestSupport artifact as a dependency. Obviously, this isn't going to fly. For the time being, The main code depending on test code is bad design. Pull out the pieces of the code from the test directories and promote it to main code. You should be able to untangle just enough for the main code to no longer depend on test. I think maybe my description was poor. The Model code itself does not rely on the test support classes, but rather the unit tests of those Model classes depend on the test support classes. Let's see if I can draw a picture... MainProject Model Module src/main/java - model classes src/test/java - unit tests for model classes TestSupport Module src/main/java - helper/builder classes - used by other modules in the Test Scope, only src/test/java - current contains unit tests for model classes for which the presence of helper/builders is needed Other modules - most of these have dependencies on both of the above modules, but only rely on TestSupport in the Test scope the more complicated unit tests are being held in the TestSupport module, but this really isn't where they belong. We need to keep the Builders in an artifact of their own because they are used by other modules for unit and functional tests. [del] On the other hand, maybe there's a better way to get my Maven build set up that will solve this problem for me. Either pull out the pieces and place into src/main/java as suggested above, or create another module that can contain the helper/build methods and have your main code depend on the helper artifacts. The helper/builder classes are in a module of their own. I think maybe my clarification, above, helps clear that up. Using another module will mean that those helper classes are already built and available for your use. Yep, that's the idea. We just have the problem of this chicken/egg business. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Quandary over testing support classes.
On Tue, Jun 16, 2009 at 11:59 AM, David C. Hicksdhi...@i-hicks.org wrote: I think my original message may not have been clear. I've tried to clarify it below. [del] I think maybe my description was poor. The Model code itself does not rely on the test support classes, but rather the unit tests of those Model classes depend on the test support classes. Let's see if I can draw a picture... MainProject Model Module src/main/java - model classes src/test/java - unit tests for model classes TestSupport Module src/main/java - helper/builder classes - used by other modules in the Test Scope, only src/test/java - current contains unit tests for model classes for which the presence of helper/builders is needed Other modules - most of these have dependencies on both of the above modules, but only rely on TestSupport in the Test scope I think I see what you are saying. Model (test) depends upon Test Support (main and test jars) I am going to assume that Test Support does not depend upon Model (either main or test) What you need to do is * to tell maven-jar-plugin to build the test jar * depend upon the test jar. See http://maven.apache.org/plugins/maven-jar-plugin/ In TestSupport you want something like build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId executions execution goals goaltest-jar/goal /goals /execution /executions /plugin /plugins /build In Model you want /dependencies ... dependency groupIdX/groupId artifactIdTestSupport/artifactId typetest-jar/type scopetest/scope /dependency /dependencies /project Does this sound correct? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Quandary over testing support classes.
Hi gang, I've been trying to find a reasonable solution to a problem we have with our Maven-based project. We have a collection of Builder classes that can create Model objects for testing purposes. These are segregated into a separate module (TestSupport) which has the Model artifact as a dependency. This works great for almost everything. The catch is that the more complex Model classes have unit tests that rely on these builders to make the test code easier to read and maintain. So, in that case the Model artifact would need to have the TestSupport artifact as a dependency. Obviously, this isn't going to fly. For the time being, the more complicated unit tests are being held in the TestSupport module, but this really isn't where they belong. We need to keep the Builders in an artifact of their own because they are used by other modules for unit and functional tests. I can see an argument that I might hear, that the Model classes should be simple beans - DTO's, if you will - that have no real need for unit tests. That's a step away from OO, though, isn't it? Maybe we're trying too hard to be as OO as possible? I really don't like the idea of stripping a class of its behavior. On the other hand, maybe there's a better way to get my Maven build set up that will solve this problem for me. Any help? Thanks, Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
