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

Re: Test History

Expand Messages
  • rsidan
    The only catch with the concept of creating a plugin is that there is a plan to change how plugins get loaded. Currently they have to be added via extending
    Message 1 of 5 , Sep 1, 2009
    • 0 Attachment
      The only catch with the concept of creating a plugin is that there is a plan to change how plugins get loaded. Currently they have to be added via extending the classpath, but that doesn't work the same way with the launching via the JAR file.

      Uncle Bob has mentioned a plan for creating a plugin folder that gets loaded into the classpath automatically, but so far that hasn't made a release.

      I would lean towards something either in a property file or command line argument that would turn it off.

      I'm not sure I'm a fan of running on a single shared server, but each environment is different.

      Dan


      --- In fitnesse@yahoogroups.com, "scottyfred" <scottyfred@...> wrote:
      >
      > The latest versions of FitNesse include a Test History feature (http://fitnesse.org/FitNesse.UserGuide.TestHistory).
      >
      > In our environment we have a small team of testers who share a common FitNesse server. With 4-5 testers writing and running tests all day long, the test history files are going to pile up pretty quickly.
      >
      > The Test History feature includes a RESTful interface for purging test history files that are older than a specified number of days. We could use curl in a cron job to clean up the test history files periodically, but we think we would rather just disable the test history feature in this shared FitNesse server.
      >
      > Has anyone else thought about disabling test history? One obvious way to do this would be with a command-line parameter, but that's not very pretty. Another option would be to pull most of the Test History functionality (the responders, the formatters) into a plugin that could be included or omitted from plugins.properties to control whether test history is captured or not.
      >
      > Any thoughts?
      >
    • Robert Martin
      ... Test history is part of a larger architectural change to FitNesse. This change allows Suites to scale to virtually any size. In the past, suite results
      Message 2 of 5 , Sep 2, 2009
      • 0 Attachment
        > Test HistoryPosted by: "scottyfred" scottyfred@...
        > scottyfredMon Aug 31, 2009 1:48 pm (PDT)
        >
        >
        > The latest versions of FitNesse include a Test History feature (http://fitnesse.org/FitNesse.UserGuide.TestHistory
        > ).
        >
        > In our environment we have a small team of testers who share a
        > common FitNesse server. With 4-5 testers writing and running tests
        > all day long, the test history files are going to pile up pretty
        > quickly.
        >
        > The Test History feature includes a RESTful interface for purging
        > test history files that are older than a specified number of days.
        > We could use curl in a cron job to clean up the test history files
        > periodically, but we think we would rather just disable the test
        > history feature in this shared FitNesse server.
        >
        > Has anyone else thought about disabling test history? One obvious
        > way to do this would be with a command-line parameter, but that's
        > not very pretty. Another option would be to pull most of the Test
        > History functionality (the responders, the formatters) into a plugin
        > that could be included or omitted from plugins.properties to control
        > whether test history is captured or not.
        >
        > Any thoughts?

        Test history is part of a larger architectural change to FitNesse.
        This change allows Suites to scale to virtually any size. In the
        past, suite results were held entirely in memory. Large suites could
        cause FitNesse to grow beyond the memory limits of the JVM, giving you
        "out of heap space" exceptions.

        Nowadays the individual test results in a suite are stored as test
        history. The suite results are then gathered from this history. This
        allows suites to be limited only by disk space.

        The upshot of this is that you daren't remove the test history
        functionality!

        For the time being, regular purges are the right solution. At some
        point in the future we'll put in a command line argument restricting
        the number of saved history files.


        ----
        Robert C. Martin (Uncle Bob) | email: unclebob@...
        Object Mentor Inc. | blog: blog.objectmentor.com
        The Agile Transition Experts | web: www.objectmentor.com
        800-338-6716 | twitter: unclebobmartin
      • scottyfred
        ... My apologies, I didn t use very clear language in my first post. I wasn t suggesting physically extracting the Test History code from the FitNesse code
        Message 3 of 5 , Sep 3, 2009
        • 0 Attachment
          --- In fitnesse@yahoogroups.com, Robert Martin <UncleBob@...> wrote:
          >
          > > Test HistoryPosted by: "scottyfred" scottyfred@...
          > > scottyfredMon Aug 31, 2009 1:48 pm (PDT)
          > >
          > >
          > > The latest versions of FitNesse include a Test History feature (http://fitnesse.org/FitNesse.UserGuide.TestHistory
          > > ).
          > >
          > > In our environment we have a small team of testers who share a
          > > common FitNesse server. With 4-5 testers writing and running tests
          > > all day long, the test history files are going to pile up pretty
          > > quickly.
          > >
          > > The Test History feature includes a RESTful interface for purging
          > > test history files that are older than a specified number of days.
          > > We could use curl in a cron job to clean up the test history files
          > > periodically, but we think we would rather just disable the test
          > > history feature in this shared FitNesse server.
          > >
          > > Has anyone else thought about disabling test history? One obvious
          > > way to do this would be with a command-line parameter, but that's
          > > not very pretty. Another option would be to pull most of the Test
          > > History functionality (the responders, the formatters) into a plugin
          > > that could be included or omitted from plugins.properties to control
          > > whether test history is captured or not.
          > >
          > > Any thoughts?
          >
          > Test history is part of a larger architectural change to FitNesse.
          > This change allows Suites to scale to virtually any size. In the
          > past, suite results were held entirely in memory. Large suites could
          > cause FitNesse to grow beyond the memory limits of the JVM, giving you
          > "out of heap space" exceptions.
          >
          > Nowadays the individual test results in a suite are stored as test
          > history. The suite results are then gathered from this history. This
          > allows suites to be limited only by disk space.
          >
          > The upshot of this is that you daren't remove the test history
          > functionality!
          >
          > For the time being, regular purges are the right solution. At some
          > point in the future we'll put in a command line argument restricting
          > the number of saved history files.
          >
          >
          > ----
          > Robert C. Martin (Uncle Bob) | email: unclebob@...
          > Object Mentor Inc. | blog: blog.objectmentor.com
          > The Agile Transition Experts | web: www.objectmentor.com
          > 800-338-6716 | twitter: unclebobmartin
          >

          My apologies, I didn't use very clear language in my first post. I wasn't suggesting physically extracting the Test History code from the FitNesse code base (it is way to ingrained for that). I was only thinking about enabling/disabling the Formatters that write out the history (and possibly the Responders to view the ouput) by including/excluding them in plugins.properties. We are thinking of making Formatters/ResultsListeners pluggable for a completely different reason, so this solution was an extension of that pluggability.

          A command-line argument to suppress History or restrict the amount of history saved would suit our purposes just fine. In the meantime we will settle for using the REST interface to purge history.

          Thanks,
          Scott
        • Robert Martin
          ... No apology necessary. Take care. FitNesse now depends on the fact that the test history files are written. If you exclude the formatter that writes the
          Message 4 of 5 , Sep 4, 2009
          • 0 Attachment
            > My apologies, I didn't use very clear language in my first post. I
            > wasn't suggesting physically extracting the Test History code from
            > the FitNesse code base (it is way to ingrained for that). I was only
            > thinking about enabling/disabling the Formatters that write out the
            > history (and possibly the Responders to view the ouput) by including/
            > excluding them in plugins.properties. We are thinking of making
            > Formatters/ResultsListeners pluggable for a completely different
            > reason, so this solution was an extension of that pluggability.

            No apology necessary.

            Take care. FitNesse now depends on the fact that the test history
            files are written. If you exclude the formatter that writes the test
            history, then a number of other things will fail, such as XML
            generation of suite results.


            ----
            Robert C. Martin (Uncle Bob) | email: unclebob@...
            Object Mentor Inc. | blog: blog.objectmentor.com
            The Agile Transition Experts | web: www.objectmentor.com
            800-338-6716 | twitter: unclebobmartin
          Your message has been successfully submitted and would be delivered to recipients shortly.