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

XP myths

Expand Messages
  • Bill de hÓra
    I think most people here realize that a good amount of what is sometimes FUD, sometimes ignorance is spread about XP/Agile/TDD. I also think this will increase
    Message 1 of 6 , Aug 5, 2003
      I think most people here realize that a good amount of what is
      sometimes FUD, sometimes ignorance is spread about XP/Agile/TDD. I
      also think this will increase as it becomes more popular.

      It occurs to me that it would be a good thing to,

      - capture the most prevalent myths about XP
      - dispell them

      and to do this in a single document. One attempt (regarding code
      ownership) is here:

      http://www.dehora.net/journal/archives/000344.html#000344

      I also think this is best done by the leaders/stalwarts of the
      community and not a casual observer like myself.

      Bill de hÓra
    • Jason Pettys
      I assume this question has been thought through many times, so just some links will probably suffice for an answer. When unit testing the data access layer,
      Message 2 of 6 , Aug 6, 2003
        I assume this question has been thought through many times, so just some
        links will probably suffice for an answer.

        When unit testing the data access layer, how can you keep the unit tests
        independent when there are lots of foreign key constraints linking the
        tables? For example, in order to test that I can save and insert a
        record into table A, I also have to insert a parent into B, but in order
        to do that I have to insert into B's parent C, etc. up four or five layers.

        Potential solutions I can think of (and their drawbacks):
        1) Add the rows in SetUp and delete them in TearDown (tedious; creates
        dependencies outside of the "unit" being tested).
        2) Drop the foreign key constraints in SetUp and delete them in TearDown
        (changing the environment for tests bothers my conscience).
        3) Implement database integrity in the data access code rather than in
        the database (Greater possibility for loss of data integrity).

        As a side note, is anyone using any good object-relational mapping
        automation with .NET?

        Thanks!
        Jason Pettys
      • banshee858
        ... some ... tests ... the ... order ... layers. ... creates ... TearDown ... in ... I tried using foreign keys one time and it made unit testing HORRIBLE.
        Message 3 of 6 , Aug 6, 2003
          >
          > I assume this question has been thought through many times, so just
          some
          > links will probably suffice for an answer.
          >
          > When unit testing the data access layer, how can you keep the unit
          tests
          > independent when there are lots of foreign key constraints linking
          the
          > tables? For example, in order to test that I can save and insert a
          > record into table A, I also have to insert a parent into B, but in
          order
          > to do that I have to insert into B's parent C, etc. up four or five
          layers.
          >
          > Potential solutions I can think of (and their drawbacks):
          > 1) Add the rows in SetUp and delete them in TearDown (tedious;
          creates
          > dependencies outside of the "unit" being tested).
          > 2) Drop the foreign key constraints in SetUp and delete them in
          TearDown
          > (changing the environment for tests bothers my conscience).
          > 3) Implement database integrity in the data access code rather than
          in
          > the database (Greater possibility for loss of data integrity).
          >

          I tried using foreign keys one time and it made unit testing
          HORRIBLE. From what I understand, unit tests are supposed to test
          things independently and as you are finding out, foreign keys really
          foul that up. If you have the opportunity to drop the foreign keys,
          do it.

          In my experience with unit testing data drive applications, you
          sometimes need to prime the DB with data. Other people say use Mock
          Objects - if you are familiar with Mock Objects, investigate them.
          If you are going to go the route of inserting "fake data", then you
          only want to insert the absolute minimum data needed to get the test
          to work. Foreign keys make you insert data you do not need for the
          test, so I would consider the foreign keys bad for unit testing (they
          might be good for data integrity, but I am not convinced).

          I have found once you create a good suite of well factored code with
          unit tests, the code will ensure ensure data integrity. IMO, that is
          where that information needs to be stored. The database should not
          be storing any business rules or store the absolute minimum
          possible. Use your code to keep your data rules in place and then
          have unit tests to ensure your code works. Remember, the data rules
          might change (instead of A -> B -> C, you might get A -> D -> C ->
          B), and making those changes in the code is easier than in the
          database.

          Carlton
        • Chris Morris
          ... I do this. Interesting side effect has been the development of a pretty good custom object rdms layer that could one day make its way from fixture to
          Message 4 of 6 , Aug 6, 2003
            Jason Pettys wrote:

            >Potential solutions I can think of (and their drawbacks):
            >1) Add the rows in SetUp and delete them in TearDown (tedious; creates
            >dependencies outside of the "unit" being tested).
            >
            I do this. Interesting side effect has been the development of a pretty
            good custom object<->rdms layer that could one day make its way from
            fixture to production.

            Yes, it's tedious, but it's thorough. It really does everything the
            production app will need to do.

            The main benefit I can see of using mocks here are for execution speed.
            If your project is big enough to have acceptance tests separate from all
            of this - then I'd say mock or drop the fkeys to get the unit tests
            running fast. If you don't have acceptance tests elsewhere, testing the
            system end-to-end, then running with mocks or sans fkeys adds some risk,
            so start with the whole shebang fixtures, then unit/mock when you need
            speed.

            Another potential option is to wrap your tests in transactions so you
            can simply rollback instead of a detailed teardown -- but this isn't
            always an option.

            >As a side note, is anyone using any good object-relational mapping
            >automation with .NET?
            >
            I started building a custom lib to do this, back when I was developing
            with the beta and rc's ... if I go back, first I'd see what commercial
            products have evolved since then.

            If there was ever enough interest, I might be able to open source what
            I've got.

            --

            Chris
            http://clabs.org/blogki
          • Charlie Poole
            This release has a number of improvements, most notably that it will run under version 1.0 of the .NET framework as installed. It includes separate
            Message 5 of 6 , Aug 6, 2003
              This release has a number of improvements, most notably that it will run
              under
              version 1.0 of the .NET framework as installed. It includes separate
              configuration
              files for use with .NET versions 1.0 and 1.1. Both configs are copied and
              the
              correct version for the current system is installed ready for use.

              NUnit 2.1 can run tests built against NUnit 2.0. A sample config file for
              use
              in this situation is included.

              Substantial changes have been made to error and exception reporting.
              The exception type is listed along with all inner exceptions. In the
              console runner, this includes a full stacktrace. The full trace for
              exceptions that are caught by the GUI runner is now available under
              the Tools | Exception Details... menu item.

              This release has been verified to install and run under Windows 98.
              The feature of watching for changes in the assemblies and reloading
              them automatically is disabled in this environment. We haven't tested
              under Windows ME, but believe it will work in that environment as well.

              NUnit 2.1 can be downloaded at http://nunit.sourceforge.net

              Charlie Poole
              cpoole@...
              http://www.pooleconsulting.com
              http://www.charliepoole.org
              http://www.nunit.org
            • Charlie Poole
              The final release of NUnit 2.1 is now available for download at http://nunit.sourceforge.net. This release has a number of improvements, most notably that it
              Message 6 of 6 , Sep 1, 2003
                The final release of NUnit 2.1 is now available for download at
                http://nunit.sourceforge.net

                This release has a number of improvements, most notably that it will
                run under version 1.0 of the .NET framework as installed. It includes
                separate configuration files for use with .NET versions 1.0 and 1.1.
                Both configs are copied and the correct version for the current system
                is installed ready for use.

                NUnit 2.1 can run tests built against NUnit 2.0. A sample config file
                for use in this situation is included.

                Substantial changes have been made to error and exception reporting.
                The exception type is listed along with all inner exceptions. In the
                console runner, this includes a full stacktrace. The full trace for
                exceptions that are caught by the GUI runner is now available under
                the Tools | Exception Details... menu item.

                This release has been verified to install and run under Windows 98.
                The feature of watching for changes in the assemblies and reloading
                them automatically is disabled in this environment. We haven't tested
                under Windows ME, but believe it will work in that environment as well.

                NUnit 2.1 can be downloaded at http://nunit.sourceforge.net

                Charlie Poole
                cpoole@...
                http://www.pooleconsulting.com
                http://www.charliepoole.org
                http://www.nunit.org



                To unsubscribe from this group, send an email to:
                extremeprogramming-seattle-unsubscribe@egroups.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.