Loading ...
Sorry, an error occurred while loading the content.

Advantages/Disadvantages to putting NUnit tests in same project with production code?

Expand Messages
  • Jim Bolla
    From what I ve seen and done, the standard practice for writing NUnit tests for a project is to create a separate project to contain the tests. So for example
    Message 1 of 42 , Jan 24, 2008
    View Source
    • 0 Attachment
      From what I've seen and done, the standard practice for writing NUnit
      tests for a project is to create a separate project to contain the
      tests. So for example if I have a project "MegaApp.DomainModel", I
      would create a corresponding project "MegaApp.DomainModel.Tests" that
      would have all the tests for that project. Recently I've been thinking
      about putting the tests directly into the "MegaApp.DomainModel"
      project in such a way that "Widget.cs" and "WidgetUnitTests.cs" would
      be right next to each other in the Solution Explorer.

      There are a couple advantages to this approach:

      * The nearness of the files will make it easier (and therefore more
      likely) that developers will work on the test in tandem with the class
      under test (CUT).
      * One can make private methods on the CUT into internal methods and
      then write tests for them, if need be.
      * Will effectively halve the number of projects in the solution (My
      current solution has 40+ non test projects), making the solution
      explorer a little less unwieldy.
      * I'm thinking this will make it easier for devs unfamiliar with NUnit
      testing to gain experience with it faster. (I'm currently trying to
      introduce the concept to 10+ developers.)

      And the only disadvantage I have thought of so far:

      * The production assemblies have a reference to NUnit and contain more
      types. Slower compilation and load time?

      Thinking about it, that disadvantage really isn't that big of a deal
      to me. So far I haven't thought of any other disadvantages. I'm
      looking for any more advantages/disadvantages for this approach vs the
      norm. Thoughts?
    • si
      Hey Casey, ... Depends, I would say it s important if you do (or plan to do) Continuous Integration. I want CC.NET to perform developer builds (i.e. soon after
      Message 42 of 42 , Jan 24, 2008
      View Source
      • 0 Attachment
        Hey Casey,

        > You don;t have to have one test project per project under test, in fact a
        > few test projects is probably plenty for a few dozen projects. Test projects
        > don't have interdependencies (or shouldn;t) so there is no need to split
        > them for purposes of assembly deployment or fucntinal seperation,

        Depends, I would say it's important if you do (or plan to do)
        Continuous Integration.

        I want CC.NET to perform developer builds (i.e. soon after an svn
        commit) if any production or test code changes, and the easiest way
        for that to happen is if the test project & code sit underneath the
        project it's testing.

        e.g. CC.NET monitors "svn://host/repo/trunk/src/Foo" for changes,
        where Foo contains:

        Foo/Foo.sln
        Foo/Core/Foo.Core.csproj
        Foo/Core/Tests/Foo.Core.Tests.csproj

        That way, any changes trigger a CI build.

        Handy when ½ your development team is on the other side of the world
        and you have CC.NET email the committer shortly after they break/fix
        the build :)

        > and the fewer test projects you have, the fewer I have to right click
        > and run each time I build in the IDE.

        With TestDriven.NET you can run all test projects for a solution with
        one right click from VS.

        cheers
        si
        --
        It's a wild world that we live in, you step to the vibe like a new
        found religion, take your position, compile your vision, futurism,
        algorithm has risen up! pfm - the western
      Your message has been successfully submitted and would be delivered to recipients shortly.