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!

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

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).

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.

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.

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.

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

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.