Issue 11 in thread-weaver: Testing sub methods

[thread...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 11 by martin.v...@gmail.com: Testing sub methods
https://code.google.com/p/thread-weaver/issues/detail?id=11

What steps will reproduce the problem?
1. use the first basic example from the UsersGuide with putIfAbsent
2. add a method
public boolean putIfAbsentNonDirect(Object o) {
return putIfAbsent(o);
}
3. run the test for both methods putIfAbsent and putIfAbsentNonDirect

What is the expected output? What do you see instead?
The test is red for putIfAbsent (correctly) but it is green for
putIfAbsentNonDirect (wrong?) even though it does the same thing. I guess
that is the way it is designed to support only first level method weaving
but why? Can I change it somehow or should I make all the sub methods
public and test them separately?

What version of the product are you using? On what operating system?
Using ThreadWeaver 0.2 on Windows 7.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[thread...@googlecode.com]

Comment #1 on issue 11 by alasdair.mackintosh: Testing sub methods
https://code.google.com/p/thread-weaver/issues/detail?id=11

Hi Martin,

This is working as intended, although I agree that the documentation needs
to be clearer.

When you use the AnnotatedTestRunner, it looks at the method invoked by the
@ThreadedMain method, and tests that. So it adds a breakpoint at every line
in that method, and then lets the second thread run to completion. But it
doesn't add breakpoints at every line in every method called by the first
method. (So in this case we are only really testing
putIfAbsentNonDirect().) You can see this yourself if you
call 'runner.setDebug(true);' on the AnnotatedTestRunner.

Making the framework interleave at every point could get expensive. How
deep do you want to go? It might be possible to add this, but I am not sure
how useful this would be.

As an alternative, you probably want to look at breakpoints. You can
control where the first thread stops and the second thread runs.

[thread...@googlecode.com]

Comment #2 on issue 11 by martin.v...@gmail.com: Testing sub methods
https://code.google.com/p/thread-weaver/issues/detail?id=11

Hello,
thanks for your answer, it would be nice to be able to go through the
methods in the class which is tested since we don�t want to make the
private methods public just because of the testability.

[thread...@googlecode.com]

Comment #3 on issue 11 by alasdair.mackintosh: Testing sub methods
https://code.google.com/p/thread-weaver/issues/detail?id=11

Have you experimented with using Breakpoints? The tutorial describes this,
and it should be possible to set a breakpoint in a private method. I know
this is less convenient. Maybe we can add an option to @ThreadedMain to
specify which method we actually want to interleave.

[thread...@googlecode.com]

Comment #4 on issue 11 by martin.v...@gmail.com: Testing sub methods
https://code.google.com/p/thread-weaver/issues/detail?id=11

The option to specify which private methods to interleave is a good
compromise, it would be the best if we could have an option to interleave
all methods in the tested class. Without these possibilities I don't think
we can use this tool.

[thread...@googlecode.com]

Updates:
Status: Started

Comment #5 on issue 11 by alasdair.mackintosh: Testing sub methods
https://code.google.com/p/thread-weaver/issues/detail?id=11

I have submitted an option that allows the test to explicitly say which
methods will be interleaved. See BaseThreadedTestRunner.setMethodOption().
There is an example in examples/UniqueListTest.java.

I haven't updated the main release yet. You will need to build from source
if you want to test this. Please let me know if this resolves the issue.

[thread...@googlecode.com]

Comment #6 on issue 11 by alasdair.mackintosh: Testing sub methods
https://code.google.com/p/thread-weaver/issues/detail?id=11

Also improved the way that the new ALL_METHODS option works. See updated
example in examples/UniqueListTest.java.

[thread...@googlecode.com]

Updates:
Status: Fixed

Comment #7 on issue 11 by alasdair.mackintosh: Testing sub methods
https://code.google.com/p/thread-weaver/issues/detail?id=11

(No comment was entered for this change.)