On 28/08/2011, at 11:37 PM, Adam Murdoch wrote: >> Putting the internalTesting main classes into testFixtures doesn't feel >> right to me. They should be in main as that's the main point of this >> project. That's the way this is currently setup. This makes more sense >> conceptually to me. > > The problem with this approach is that the semantics of the main source set > changes based on the project it happens to live in. This means that our build > infrastructure needs to know the purpose of the project in order to decide > which rules to apply to which code. For example, the code in internalTesting > main is semantically the same as the code in core testFixtures, and so should > have the same rules applied to it. The build needs to know the > internalTesting's purpose is to provide test fixtures, in order to do this. A > developer must also have this mapping in their heads when deciding which > source directory to add a source file.
A good point. > I think things would be much simpler if the meaning of a source set were the > fixed and independent the purpose of the project. > > Perhaps the problem here is more with the partitioning of the projects. You > can think of the core project as having 2 broad categories of production code: > * Domain independent infrastructure and services. > * Domain-specific APIs, DSLs and services. It would help me if you gave some examples of each category. I think I follow but want to be sure. > This is a very similar to the distinction between internalTesting main and > core testFixtures. So, some options would be: > * Move internalTesting main into core testFixtures and axe internalTesting. If we did this, integration testing would depend on core testFixtures (and therefore all of core's runtime) which I think is too much. All that's left in internalTesting now are very generic utilities that are used for both unit and integration testing. We have 3 categories of testing code: 1. generic utilities helpful for writing tests 2. unit testing utilities (depends on 1 and core) 3. integration testing utilities (depends on 1 and core) I don't think 3 should depend on core, it should just depend on the tooling-api (and launcher). If we leave these as three things we could achieve this, but if we merge 2 and 3 this will not be possible. It feels that unit and integration testing are different enough that they shouldn't be lumped together, but perhaps this distinction is unnecessary. > * Split core into domain-independent and domain-specified pieces. What is > currently in internalTesting main becomes the testFixtures of the > domain-independent project. We need to do this at some point, anyway, as > tooling API uses some generic infrastructure from core, but must not drag in > all the unnecessary runtime dependencies of the domain specific parts of core. This doesn't feel quite right conceptually to me as the main and testFixtures source sets of this domain-independent project won't have any real relationship (i.e. the testFixture utils aren't about testing the code from main) but I think it's close enough that it's the way to go to reduce the number of sub projects. > For the internalIntegTest project, its purpose is to provide the public > integration testing infrastructure; it just happens to have an empty main > source set at the moment. It should be called 'integTest' and its main source > set should be called testFixtures. I wasn't sure whether this would be where the public integration testing infrastructure is birthed but I guess it can be. I think we need to be very clear on what is public and what is not for these testing utilities. If we don't do this we will be forced into supporting non public API (which there is always a risk of but this won't help). Perhaps the way to do this is via package names, like we already do in some places (i.e. anything matching **.internal.** is not public). The only downside I can see to this is that it would mean that packages may not always align, e.g. you want to provide a non public test utility for a public class, but I think that's acceptable. I need to think through this a little more. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
