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

Separate Package for Test Cases or not ?

Expand Messages
  • lewold@yahoo.com
    According this topic I found two different views: -) In the sourceforge FAQ they propose to use a separate test package for the unit tests. -) In various
    Message 1 of 6 , Nov 8, 2001
    View Source
    • 0 Attachment
      According this topic I found two different views:
      -) In the sourceforge FAQ they propose to use a separate test package
      for the unit tests.
      -) In various documents linked on the JUnit homepage (e.g. JUnit bets
      practices) they propose to keep the unit tests in the package of the
      classes to be tested.

      Personally I like the separate package more, as I don't want to ship
      the unit tests with the project. At no costs I want to manually
      exclude the test classes during shipment. Addiditonally I simply find
      this approach more structured - in our last project we had for each
      package a .test package.
      The separate package however has the main drawback for me that I cant
      test package private methods. This forces me to make more methods
      public than I want just for testing purposes.

      What are your experiences and preferences in this area ?

      Chris Lewold
    • Jim Cheesman
      ... I have them in the same package, and use ant to exclude them when I do a full build. This does force you to use a consistent naming scheme for the classes,
      Message 2 of 6 , Nov 8, 2001
      View Source
      • 0 Attachment
        At 10:20 AM 08/11/01, you wrote:
        >According this topic I found two different views:
        >-) In the sourceforge FAQ they propose to use a separate test package
        >for the unit tests.
        >-) In various documents linked on the JUnit homepage (e.g. JUnit bets
        >practices) they propose to keep the unit tests in the package of the
        >classes to be tested.
        >
        >Personally I like the separate package more, as I don't want to ship
        >the unit tests with the project. At no costs I want to manually
        >exclude the test classes during shipment. Addiditonally I simply find
        >this approach more structured - in our last project we had for each
        >package a .test package.
        >The separate package however has the main drawback for me that I cant
        >test package private methods. This forces me to make more methods
        >public than I want just for testing purposes.
        >
        >What are your experiences and preferences in this area ?


        I have them in the same package, and use ant to exclude them when I do a
        full build.

        This does force you to use a consistent naming scheme for the classes, but
        I don't find that to be too much of a problem.




        --

        * Jim Cheesman *
        Trabajo:
        jchees@... - (34)(91) 724 9200 x 2360
        In retrospect it becomes clear
        that hindsight is definitely overrated
      • Eric Vought
        Why not do both? (e.g.):
        Message 3 of 6 , Nov 8, 2001
        View Source
        • 0 Attachment
          Why not do both? (e.g.):

          <jutils>
          <src>
          <com>
          <qlue>
          <util>
          <getopt/>
          <assert/>
          <logging/>
          </util>
          </qlue>
          </com>
          </src>
          <bvt>
          <com>
          <qlue>
          <util>
          <getopt/>
          <assert/>
          <logging/>
          </util>
          </qlue>
          </com>
          </bvt>
          <class> ... </class>
          <bvtclass> ... </bvtclass>
          <doc/>
          <testrun/>
          <lib/>
          </jutils>

          The bvt (Build Verification Tests) directory contains the test cases and
          duplicates the same package structure as the classes-under-test. The
          compiler doesn't care that they are in separate trees as long as the
          package structure is the same. This allows the tests to be compiled and
          packaged separately but still have access to package methods and
          classes. This is what we are beginning to do in all of our projects.

          On Thu, 8 Nov 2001 lewold@... wrote:

          > According this topic I found two different views:
          > -) In the sourceforge FAQ they propose to use a separate test package
          > for the unit tests.
          > -) In various documents linked on the JUnit homepage (e.g. JUnit bets
          > practices) they propose to keep the unit tests in the package of the
          > classes to be tested.
          >
          > Personally I like the separate package more, as I don't want to ship
          > the unit tests with the project. At no costs I want to manually
          > exclude the test classes during shipment. Addiditonally I simply find
          > this approach more structured - in our last project we had for each
          > package a .test package.
          > The separate package however has the main drawback for me that I cant
          > test package private methods. This forces me to make more methods
          > public than I want just for testing purposes.
          >
          > What are your experiences and preferences in this area ?
          >
          > Chris Lewold
          >
          >
          > To unsubscribe from this group, send an email to:
          > junit-unsubscribe@yahoogroups.com
          >
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
          >

          --
          Eric Vought
          Chief Technical Officer - QLUE Consulting, Inc.

          evought@... toll-free: 888-771-3538 RTP area: 919-816-9901
        • Jason Rogers
          With all of the great tools available (e.g. IDEs, Ant, make) this really becomes a matter of choice. I prefer having a different package for the tests as I
          Message 4 of 6 , Nov 8, 2001
          View Source
          • 0 Attachment
            With all of the great tools available (e.g. IDEs, Ant,
            make) this really becomes a matter of choice. I prefer
            having a different package for the tests as I prefer to
            test only the public interfaces (for which I depend on the
            Smalltalk-ism where, technically, everything is public).
            If the public interface is written effectively it will
            prove the correctness of the private interface (which
            includes private, protected, and package protected
            methods).

            Some may argue that bugs can creep into the privates
            unawares. This becomes less and less of an option as the
            public interface's design improves. I avoid the white box
            approach like the plague because it affords me the
            opportunity to make my design better. A little extra work
            up front usually pays off for me in the end.

            ...just my $0.02

            -jason

            --- Eric Vought <evought@...> wrote:
            > Why not do both? (e.g.):
            >
            > <jutils>
            > <src>
            > <com>
            > <qlue>
            > <util>
            > <getopt/>
            > <assert/>
            > <logging/>
            > </util>
            > </qlue>
            > </com>
            > </src>
            > <bvt>
            > <com>
            > <qlue>
            > <util>
            > <getopt/>
            > <assert/>
            > <logging/>
            > </util>
            > </qlue>
            > </com>
            > </bvt>
            > <class> ... </class>
            > <bvtclass> ... </bvtclass>
            > <doc/>
            > <testrun/>
            > <lib/>
            > </jutils>
            >
            > The bvt (Build Verification Tests) directory contains the
            > test cases and
            > duplicates the same package structure as the
            > classes-under-test. The
            > compiler doesn't care that they are in separate trees as
            > long as the
            > package structure is the same. This allows the tests to
            > be compiled and
            > packaged separately but still have access to package
            > methods and
            > classes. This is what we are beginning to do in all of
            > our projects.
            >
            > On Thu, 8 Nov 2001 lewold@... wrote:
            >
            > > According this topic I found two different views:
            > > -) In the sourceforge FAQ they propose to use a
            > separate test package
            > > for the unit tests.
            > > -) In various documents linked on the JUnit homepage
            > (e.g. JUnit bets
            > > practices) they propose to keep the unit tests in the
            > package of the
            > > classes to be tested.
            > >
            > > Personally I like the separate package more, as I don't
            > want to ship
            > > the unit tests with the project. At no costs I want to
            > manually
            > > exclude the test classes during shipment. Addiditonally
            > I simply find
            > > this approach more structured - in our last project we
            > had for each
            > > package a .test package.
            > > The separate package however has the main drawback for
            > me that I cant
            > > test package private methods. This forces me to make
            > more methods
            > > public than I want just for testing purposes.
            > >
            > > What are your experiences and preferences in this area
            > ?
            > >
            > > Chris Lewold
            > >
            > >
            > > To unsubscribe from this group, send an email to:
            > > junit-unsubscribe@yahoogroups.com
            > >
            > >
            > > Your use of Yahoo! Groups is subject to
            > http://docs.yahoo.com/info/terms/
            > >
            > >
            > >
            >
            > --
            > Eric Vought
            > Chief Technical Officer - QLUE Consulting, Inc.
            >
            > evought@... toll-free: 888-771-3538 RTP area:
            > 919-816-9901
            >
            >
            > ------------------------ Yahoo! Groups Sponsor
            >
            > To unsubscribe from this group, send an email to:
            > junit-unsubscribe@yahoogroups.com
            >
            >
            > Your use of Yahoo! Groups is subject to
            > http://docs.yahoo.com/info/terms/
            >
            >


            =====
            -----------------------------------------
            Keep it simple...
            (1 Corinthians 2:2, Galatians 2:20, 6:14)

            __________________________________________________
            Do You Yahoo!?
            Find a job, post your resume.
            http://careers.yahoo.com
          • Eric Vought
            I don t test private methods per se, for just the reasons you site. If private methods get complex enough to require testing they need to be refactored out
            Message 5 of 6 , Nov 8, 2001
            View Source
            • 0 Attachment
              I don't test "private" methods per se, for just the reasons you site. If
              private methods get complex enough to require testing they need to be
              refactored out into utility classes. However, I do see a need with APIs to
              protect end-users from classes which are solely implementation details and
              which are subject to change. These facilities are package protected. If
              they survive the test of time, they can be made public, but it is very
              hard to make a public facility private or take it away. If it's public,
              someone in the field will use it and will scream when it's changed. Using
              package access controls allows me the freedom to refactor and improve that
              design. The unit tests give me confidence that I've done it right.

              On Thu, 8 Nov 2001, Jason Rogers wrote:

              > With all of the great tools available (e.g. IDEs, Ant,
              > make) this really becomes a matter of choice. I prefer
              > having a different package for the tests as I prefer to
              > test only the public interfaces (for which I depend on the
              > Smalltalk-ism where, technically, everything is public).
              > If the public interface is written effectively it will
              > prove the correctness of the private interface (which
              > includes private, protected, and package protected
              > methods).
              >
              > Some may argue that bugs can creep into the privates
              > unawares. This becomes less and less of an option as the
              > public interface's design improves. I avoid the white box
              > approach like the plague because it affords me the
              > opportunity to make my design better. A little extra work
              > up front usually pays off for me in the end.
              >
              > ...just my $0.02
              >
              > -jason
              >
              > --- Eric Vought <evought@...> wrote:
              > > Why not do both? (e.g.):
              > >
              > > <jutils>
              > > <src>
              > > <com>
              > > <qlue>
              > > <util>
              > > <getopt/>
              > > <assert/>
              > > <logging/>
              > > </util>
              > > </qlue>
              > > </com>
              > > </src>
              > > <bvt>
              > > <com>
              > > <qlue>
              > > <util>
              > > <getopt/>
              > > <assert/>
              > > <logging/>
              > > </util>
              > > </qlue>
              > > </com>
              > > </bvt>
              > > <class> ... </class>
              > > <bvtclass> ... </bvtclass>
              > > <doc/>
              > > <testrun/>
              > > <lib/>
              > > </jutils>
              > >
              > > The bvt (Build Verification Tests) directory contains the
              > > test cases and
              > > duplicates the same package structure as the
              > > classes-under-test. The
              > > compiler doesn't care that they are in separate trees as
              > > long as the
              > > package structure is the same. This allows the tests to
              > > be compiled and
              > > packaged separately but still have access to package
              > > methods and
              > > classes. This is what we are beginning to do in all of
              > > our projects.
              > >
              > > On Thu, 8 Nov 2001 lewold@... wrote:
              > >
              > > > According this topic I found two different views:
              > > > -) In the sourceforge FAQ they propose to use a
              > > separate test package
              > > > for the unit tests.
              > > > -) In various documents linked on the JUnit homepage
              > > (e.g. JUnit bets
              > > > practices) they propose to keep the unit tests in the
              > > package of the
              > > > classes to be tested.
              > > >
              > > > Personally I like the separate package more, as I don't
              > > want to ship
              > > > the unit tests with the project. At no costs I want to
              > > manually
              > > > exclude the test classes during shipment. Addiditonally
              > > I simply find
              > > > this approach more structured - in our last project we
              > > had for each
              > > > package a .test package.
              > > > The separate package however has the main drawback for
              > > me that I cant
              > > > test package private methods. This forces me to make
              > > more methods
              > > > public than I want just for testing purposes.
              > > >
              > > > What are your experiences and preferences in this area
              > > ?
              > > >
              > > > Chris Lewold
              > > >
              > > >
              > > > To unsubscribe from this group, send an email to:
              > > > junit-unsubscribe@yahoogroups.com
              > > >
              > > >
              > > > Your use of Yahoo! Groups is subject to
              > > http://docs.yahoo.com/info/terms/
              > > >
              > > >
              > > >
              > >
              > > --
              > > Eric Vought
              > > Chief Technical Officer - QLUE Consulting, Inc.
              > >
              > > evought@... toll-free: 888-771-3538 RTP area:
              > > 919-816-9901
              > >
              > >
              > > ------------------------ Yahoo! Groups Sponsor
              > >
              > > To unsubscribe from this group, send an email to:
              > > junit-unsubscribe@yahoogroups.com
              > >
              > >
              > > Your use of Yahoo! Groups is subject to
              > > http://docs.yahoo.com/info/terms/
              > >
              > >
              >
              >
              > =====
              > -----------------------------------------
              > Keep it simple...
              > (1 Corinthians 2:2, Galatians 2:20, 6:14)
              >
              > __________________________________________________
              > Do You Yahoo!?
              > Find a job, post your resume.
              > http://careers.yahoo.com
              >
              >
              > To unsubscribe from this group, send an email to:
              > junit-unsubscribe@yahoogroups.com
              >
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >
              >
              >

              --
              Eric Vought
              Chief Technical Officer - QLUE Consulting, Inc.

              evought@... toll-free: 888-771-3538 RTP area: 919-816-9901
            • David Hooker
              I do the same thing, but put the tests in a ./tests subdir and have ant exclude the directory. ... From: Jim Cheesman [mailto:jchees@msl.es] Sent: Thursday,
              Message 6 of 6 , Nov 8, 2001
              View Source
              • 0 Attachment
                I do the same thing, but put the tests in a ./tests subdir and have ant
                exclude the directory.

                -----Original Message-----
                From: Jim Cheesman [mailto:jchees@...]
                Sent: Thursday, November 08, 2001 4:37 AM
                To: junit@yahoogroups.com
                Subject: Re: [junit] Separate Package for Test Cases or not ?


                At 10:20 AM 08/11/01, you wrote:
                >According this topic I found two different views:
                >-) In the sourceforge FAQ they propose to use a separate test package
                >for the unit tests.
                >-) In various documents linked on the JUnit homepage (e.g. JUnit bets
                >practices) they propose to keep the unit tests in the package of the
                >classes to be tested.
                >
                >Personally I like the separate package more, as I don't want to ship
                >the unit tests with the project. At no costs I want to manually
                >exclude the test classes during shipment. Addiditonally I simply find
                >this approach more structured - in our last project we had for each
                >package a .test package.
                >The separate package however has the main drawback for me that I cant
                >test package private methods. This forces me to make more methods
                >public than I want just for testing purposes.
                >
                >What are your experiences and preferences in this area ?


                I have them in the same package, and use ant to exclude them when I do a

                full build.

                This does force you to use a consistent naming scheme for the classes,
                but
                I don't find that to be too much of a problem.




                --

                * Jim Cheesman *
                Trabajo:
                jchees@... - (34)(91) 724 9200 x 2360
                In retrospect it becomes clear
                that hindsight is definitely overrated



                To unsubscribe from this group, send an email to:
                junit-unsubscribe@yahoogroups.com


                Your use of Yahoo! Groups is subject to
                http://docs.yahoo.com/info/terms/
              Your message has been successfully submitted and would be delivered to recipients shortly.