Commons SCXML
  1. Commons SCXML
  2. SCXML-93

SCXMLTestHelper generates a lot of serialisation files which are not tidied up

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.10
    • Labels:
      None

      Description

      SCXMLTestHelper generates files to test serialisation of classes in testExecutorSerializability() and testModelSerializability().

      These files are only used temporarily, but are not cleared up at the end of a run.
      They can be replaced by using ByteArray classes.

        Activity

        Hide
        Rahul Akolkar added a comment -

        I think the aspect of tidying up here is no different from what folks using any of the builds should expect – to elaborate, lets say you execute this command:

        mvn test

        (or 'maven test', or 'ant'), you'll find a bunch of artifacts created in the target directory. These persist until you clean the build, so in the above case a:

        mvn clean

        will do the trick. The serialization files follow a similar pattern, they can be cleaned using the corresponding clean command.

        A useful advantage of using File I/O is that the artifacts can be introspected once you run the tests and you can observe how certain changes to the datamodel or history affect size on disk etc.

        You are right that this can be replaced by using ByteArray I/O instead, but at this point its unclear we should (its much harder to introspect serializations or track serialization timelines that way).

        Resolving as Won't Fix.

        Show
        Rahul Akolkar added a comment - I think the aspect of tidying up here is no different from what folks using any of the builds should expect – to elaborate, lets say you execute this command: mvn test (or 'maven test', or 'ant'), you'll find a bunch of artifacts created in the target directory. These persist until you clean the build, so in the above case a: mvn clean will do the trick. The serialization files follow a similar pattern, they can be cleaned using the corresponding clean command. A useful advantage of using File I/O is that the artifacts can be introspected once you run the tests and you can observe how certain changes to the datamodel or history affect size on disk etc. You are right that this can be replaced by using ByteArray I/O instead, but at this point its unclear we should (its much harder to introspect serializations or track serialization timelines that way). Resolving as Won't Fix.
        Hide
        Sebb added a comment -

        Yes, testing generates other artifacts, however these are regenerated for each run - they don't normally accumulate as in this case.

        There's also no easy way to tie the file to the test case, so I don't see what purpose is served by keeping the files.
        If you really want to keep the files, name them after the testcases that use them. At least then the number of files would be limited.

        Show
        Sebb added a comment - Yes, testing generates other artifacts, however these are regenerated for each run - they don't normally accumulate as in this case. There's also no easy way to tie the file to the test case, so I don't see what purpose is served by keeping the files. If you really want to keep the files, name them after the testcases that use them. At least then the number of files would be limited.
        Hide
        Rahul Akolkar added a comment -

        When running a single (problematic or new) test at a time, as I prefer to do, its actually not difficult to locate serialization artifacts (they are usually < 5 per test, and timestamp order corresponds to document order of serialization).

        I agree on accumulation, and since you insist on this, I don't mind those bits being redone such that we use names that match the testcases etc. I agree its an improvement since the number would be limited on a complete run (or many runs) as you say above.

        However, its not something I personally care to do (which is why the Won't Fix before).

        So I'm setting the fix version to 1.0 (which currently means 'some time in the future if a well-tested patch appears on this ticket').

        Show
        Rahul Akolkar added a comment - When running a single (problematic or new) test at a time, as I prefer to do, its actually not difficult to locate serialization artifacts (they are usually < 5 per test, and timestamp order corresponds to document order of serialization). I agree on accumulation, and since you insist on this, I don't mind those bits being redone such that we use names that match the testcases etc. I agree its an improvement since the number would be limited on a complete run (or many runs) as you say above. However, its not something I personally care to do (which is why the Won't Fix before). So I'm setting the fix version to 1.0 (which currently means 'some time in the future if a well-tested patch appears on this ticket').
        Hide
        Sebb added a comment -

        It's not too difficult to walk the call stack to find a calling method with the name textXXX, but this does not uniquely identify all usages.

        So I suggest just replacing the millisecond stamp (which is not necessarily unique, by the way) with a simple int counter.
        This can be a static (class) variable. If the test is re-run without reloading the class, then the counter will increase, but at least repeated "mvn test" runs won't create lots of files.

        Is that OK?

        Show
        Sebb added a comment - It's not too difficult to walk the call stack to find a calling method with the name textXXX, but this does not uniquely identify all usages. So I suggest just replacing the millisecond stamp (which is not necessarily unique, by the way) with a simple int counter. This can be a static (class) variable. If the test is re-run without reloading the class, then the counter will increase, but at least repeated "mvn test" runs won't create lots of files. Is that OK?
        Hide
        Sebb added a comment -

        Patch to replace millisecond suffix with integer suffix to reduce number of files generated (and ensure uniqueness)

        Show
        Sebb added a comment - Patch to replace millisecond suffix with integer suffix to reduce number of files generated (and ensure uniqueness)
        Hide
        Rahul Akolkar added a comment -

        Patch looks good, thanks. As a minor nit, I'll request that you add the static int and the new method towards the top where the constants for the serialization tests are defined.

        Show
        Rahul Akolkar added a comment - Patch looks good, thanks. As a minor nit, I'll request that you add the static int and the new method towards the top where the constants for the serialization tests are defined.
        Hide
        Sebb added a comment -

        Updated location for int and method

        Show
        Sebb added a comment - Updated location for int and method
        Hide
        Rahul Akolkar added a comment -

        It would've been fine to just apply this one (atleast thats what I intended to say in the last comment)

        Updating fix version to v0.10 since a patch is now available (I'm assuming you'll commit and resolve this).

        Show
        Rahul Akolkar added a comment - It would've been fine to just apply this one (atleast thats what I intended to say in the last comment) Updating fix version to v0.10 since a patch is now available (I'm assuming you'll commit and resolve this).
        Hide
        Sebb added a comment -

        Fixed in trunk:

        URL: http://svn.apache.org/viewvc?rev=724565&view=rev
        Log:
        SCXML-93: SCXMLTestHelper generates a lot of serialisation files which are not tidied up

        and in branch J6:

        URL: http://svn.apache.org/viewvc?rev=724567&view=rev
        Log:
        SCXML-93: SCXMLTestHelper generates a lot of serialisation files which are not tidied up

        Show
        Sebb added a comment - Fixed in trunk: URL: http://svn.apache.org/viewvc?rev=724565&view=rev Log: SCXML-93 : SCXMLTestHelper generates a lot of serialisation files which are not tidied up and in branch J6: URL: http://svn.apache.org/viewvc?rev=724567&view=rev Log: SCXML-93 : SCXMLTestHelper generates a lot of serialisation files which are not tidied up

          People

          • Assignee:
            Unassigned
            Reporter:
            Sebb
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development