14 Replies Latest reply on Feb 18, 2011 10:25 AM by perneto

    Code duplication in ProtocolProjectorTest / running tests in an IDE

    perneto

      I'm adding a few more tests to the CTK, and I've noticed there is a lot of code duplication in ProtocolProjectorTest. Is this on purpose? I know some people prefer making test code as obvious as possible, even if that means a lot of copy-paste.

       

      Another related question: how do you run the tests in an IDE? They're looking for the Scribble files using System.getSystemResourceAsStream, which doesn't work in my IDE. I've been changing the code to a FileInputStream while I run the tests, but I always need to change it back to make the tests work in Maven.

        • 1. Code duplication in ProtocolProjectorTest / running tests in an IDE
          objectiser

          Hi Olivier

          Olivier Pernet wrote:

           

          I'm adding a few more tests to the CTK, and I've noticed there is a lot of code duplication in ProtocolProjectorTest. Is this on purpose? I know some people prefer making test code as obvious as possible, even if that means a lot of copy-paste.

           

          I normally try to factor out the main common aspects of the tests, but sometimes get lazy and just copy

           

          Olivier Pernet wrote:

           

          Another related question: how do you run the tests in an IDE? They're looking for the Scribble files using System.getSystemResourceAsStream, which doesn't work in my IDE. I've been changing the code to a FileInputStream while I run the tests, but I always need to change it back to make the tests work in Maven.

           

          In Eclipse the src/main/resources and src/test/resources are also added to the classpath of the project. Not sure what IDE you are using, but I assume that it should be possible to add other folders to the classpath?

           

          Regards

          Gary

          • 2. Re: Code duplication in ProtocolProjectorTest / running tests in an IDE
            perneto

            Gary Brown wrote:

             

            Hi Olivier

            Olivier Pernet wrote:

             

            I'm adding a few more tests to the CTK, and I've noticed there is a lot of code duplication in ProtocolProjectorTest. Is this on purpose? I know some people prefer making test code as obvious as possible, even if that means a lot of copy-paste.

             

            I normally try to factor out the main common aspects of the tests, but sometimes get lazy and just copy

             

            Ok, I'll factor some more stuff out then.

             

             

            Olivier Pernet wrote:

             

            Another related question: how do you run the tests in an IDE? They're looking for the Scribble files using System.getSystemResourceAsStream, which doesn't work in my IDE. I've been changing the code to a FileInputStream while I run the tests, but I always need to change it back to make the tests work in Maven.

             

            In Eclipse the src/main/resources and src/test/resources are also added to the classpath of the project. Not sure what IDE you are using, but I assume that it should be possible to add other folders to the classpath?

             

            Aha, I wasn't sure the SystemClassLoader was using the user class path. I made sure *.spr files were copied, and now I'm fine. (IntelliJ IDEA only copies resource files into its classpath if they match a user-defined name pattern). Thanks!

            • 3. Code duplication in ProtocolProjectorTest / running tests in an IDE
              perneto

              Olivier Pernet wrote:

               

              Gary Brown wrote:

               

              Hi Olivier

              Olivier Pernet wrote:

               

              I'm adding a few more tests to the CTK, and I've noticed there is a lot of code duplication in ProtocolProjectorTest. Is this on purpose? I know some people prefer making test code as obvious as possible, even if that means a lot of copy-paste.

               

              I normally try to factor out the main common aspects of the tests, but sometimes get lazy and just copy

               

              Ok, I'll factor some more stuff out then.

              I did the refactoring today, tell me if you dislike it. Right now test names are uninformative, but there's no good way to fix it with the JUnit 4 API (see http://stackoverflow.com/questions/650894/change-test-name-of-parameterized-tests).

               

              Maybe I'll use the JUnit 3 API and implement this little trick: http://snippets.dzone.com/posts/show/752

              • 4. Code duplication in ProtocolProjectorTest / running tests in an IDE
                objectiser

                I don't think we should go back to JUnit 3.

                 

                The other approach would be to return to the previous approach, with separate test methods, but essentially just have a single function call with the parameters?

                • 5. Code duplication in ProtocolProjectorTest / running tests in an IDE
                  perneto

                  Gary Brown wrote:

                   

                  I don't think we should go back to JUnit 3.

                   

                   

                   

                  No need to change the JAR version: JUnit 4 includes all the JUnit 3 APIs.

                  The other approach would be to return to the previous approach, with separate test methods, but essentially just have a single function call with the parameters?

                   

                  It's still quite long-winded... That's what I did at first (that's why I introduced the checkProjectsSuccessfully method).

                  • 6. Code duplication in ProtocolProjectorTest / running tests in an IDE
                    objectiser

                    Olivier Pernet wrote:

                     

                    Gary Brown wrote:

                     

                    I don't think we should go back to JUnit 3.

                     

                     

                     

                    No need to change the JAR version: JUnit 4 includes all the JUnit 3 APIs.

                     

                    I know, but its possible the JUnit3 APIs will be deprecated earlier - so if possible sticking with 4 annotations would be better.

                     

                     

                    Olivier Pernet wrote:


                    It's still quite long-winded... That's what I did at first (that's why I introduced the checkProjectsSuccessfully method).

                    Yes its long winded by is not that much different to having the array of test details.

                    • 7. Code duplication in ProtocolProjectorTest / running tests in an IDE
                      perneto

                      Olivier Pernet wrote:


                      It's still quite long-winded... That's what I did at first (that's why I introduced the checkProjectsSuccessfully method).

                      Yes its long winded by is not that much different to having the array of test details.

                       

                      OK, you convinced me, I'll make the change.

                      • 8. Code duplication in ProtocolProjectorTest / running tests in an IDE
                        objectiser

                        Before you make the change, I've had second thoughts about using JUnit3 - it is unlikely these would be deprecated for a long time, if ever.

                         

                        So I think we have two options:

                        a) JUnit3

                        b) JUnit4 with individual test methods

                         

                        but one possible advantage of (b) is being able to set a break point on the test.

                        • 9. Code duplication in ProtocolProjectorTest / running tests in an IDE
                          perneto

                          Right, that's about it. On the other hand you can always set a conditional breakpoint comparing the test parameter to the file name you're interested in, so I wouldn't take that into account too much.

                           

                          Using the JUnit 3 approach, we might even manage to get rid of the list of file names altogether, using some classpath hacks to list the contents of the global/ and local/ directories. Then we'll just need to add files in the right directory to add new tests.

                          • 10. Code duplication in ProtocolProjectorTest / running tests in an IDE
                            objectiser

                            Olivier Pernet wrote:

                             

                            Using the JUnit 3 approach, we might even manage to get rid of the list of file names altogether, using some classpath hacks to list the contents of the global/ and local/ directories. Then we'll just need to add files in the right directory to add new tests.

                             

                            Feel free to give it ago - I assume you mean it would work based on the current file name conventions, to ensure it was easy to determine the correspondence between the global and local models.

                            • 11. Code duplication in ProtocolProjectorTest / running tests in an IDE
                              perneto

                              Actually, I'm already using the file name to extract which Role to project for... but I didn't consider that a hack more like convention over configuration.

                               

                              The hack part is to get around the fact that ClassLoader doesn't have any methods to list the files in a "directory" on the classpath (could be jar entries too). (getResources sounds like it might work, but doesn't). So, to get around that, you can grab java.class.path and try things on it until you find the directory.

                              • 12. Code duplication in ProtocolProjectorTest / running tests in an IDE
                                objectiser

                                You just need to get the resource URL for a well known file - so might need a single placeholder, and then extract the file path from that?

                                • 13. Code duplication in ProtocolProjectorTest / running tests in an IDE
                                  perneto

                                  Aha, that's clever. I'll try that.

                                  • 14. Code duplication in ProtocolProjectorTest / running tests in an IDE
                                    perneto

                                    Gary Brown wrote:

                                     

                                    You just need to get the resource URL for a well known file - so might need a single placeholder, and then extract the file path from that?

                                    Actually that doesn't seem possible, as you need to list the contents of a classpath "directory" - having an InputStream for a well-known file doesn't help (unless you meant we should have a list of file names inside this well-known file)?

                                     

                                     

                                    I tried that, it works fine in my IDE, but not with Maven... I think I'll give up, it's getting too brittle.