Currently, that is correct, so it's the best place to start. In the future, we will have integration tests specific to Mono Linux, Mono Solaris, etc, as well as Windows What I see is that we need to create an integration testing component that can read the build platform capabilities, match those to the build requirements and determine which tests to run. In some cases, the integration testing component may choose to ignore certain tests if the build platform could not support them. In this way, someone can create a target platform and run the integration tests to see if NMaven will run on that specific platform.
Shane On 6/15/07, Evan Worley <[EMAIL PROTECTED]> wrote:
Even with the nmaven.settings.xml, we would still need a Windows machine in order to run all of the integration tests, correct? On 6/15/07, Shane Isbell <[EMAIL PROTECTED]> wrote: > > The motivating reason for adding the nmaven-settings.xml was to support > integration testing. As I added integration tests, it became time > consuming > to create the same tests for Mono, Windows and dotGNU. That also did not > take into account using of different frameworks (2 and now 3 for Microsoft > and more for Mono, with its various vendor versions). > > For a single build machine, what Continuum or CruiseControl would need to > be > able to do is to swap out the nmaven-settings.xml file (using the - > Dnmaven.settings=<file_path> option) and run IT tests for each settings > file. This allows, say installing multiple versions of Mono that we > claim NMaven supports and testing out each version with a separate pass. > > This also brings about another area that we need to look into with > bringing > NMaven and Maven closer together: the nmaven-settings.xml file describes > the platform capabilities, which is another word for profile, albeit a > more > descriptive one. > > Shane > > > On 6/15/07, Evan Worley <[EMAIL PROTECTED]> wrote: > > > > That all sounds great. The profiles solution for platform specific > tests > > would work as well, though ideally we could setup an environment which > was > > able to run all the integration tests. > > > > I agree that the most important thing is to get this started, compiling > > the > > code, and running the unit tests. Once we get that baseline we can > slowly > > roll out more features, like the integration tests, code coverage, etc. > > > > -Evan > > > > On 6/15/07, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > > > > > > On 15/06/2007, at 5:19 PM, Evan Worley wrote: > > > > > > > When you say "we don't have the software installed" are you > > > > referring to the > > > > required frameworks for the integration tests (Microsoft .NET > > > > platform for > > > > example)? > > > > > > That's right. > > > > > > > > > > > I believe the only operating system that is capable of passing all > > > > integration tests in Windows, due to MS .net platform only being > > > > available > > > > for windows. > > > > > > Right - I'll look into this. > > > > > > > > > > > Another option is to refine our testing strategy to enable > > > > functional/unit > > > > tests to be easily written for maven plugins. If this were > > > > possible (maybe > > > > it is and I just don't know how), then we could rely on these tests > > > > to be > > > > ran and rely less on the Continuum server running the integration > > > > tests. > > > > > > Ideally, both types of tests would run in a continuous integration > > > server, with the unit tests not relying on any frameworks, and the > > > integration tests running under a profile that is only done on > > > platforms that support them. > > > > > > The most important step is that we get the code compiling and the > > > unit tests running that can so far, so we can probably start adding > > > projects to the existing instance where that's possible. > > > > > > After that, we could set up mono on solaris and run some of the > > > additional tests against that, then go from there onto other > > > platforms as we are able to get them going. > > > > > > WDYT? > > > > > > - Brett > > > > > >
