Do we need to look at VirtualBox, or some other VM that we can boot onto the
servers and dispatch multiple machines onto so that we can create the type of
test scenarios that make sense in these situations?
Gregg Wonderly
On 10/21/2010 4:42 PM, Patricia Shanahan wrote:
To me, the idea of something as much concerned with remote activity as a Jini
implementation not having a single QA test that uses more than one computer
seems implausible and a bit alarming. A developer loading up enough services on
his workstation for it to play the other computer in some remote tests seems
quite plausible.
On the other hand, I have not looked at all at the tests in question, so they
may indeed be tests that *must* run single system and just mention "resendes"
for historical reasons. In that case, I'll put creating some multi-computer
tests, and finding a way of running them, on my to-do list, unless there is a
really convincing argument that River cannot possibly have a remote-only bug.
Patricia
On 10/21/2010 11:43 AM, Gregg Wonderly wrote:
Resendes was one of the original Sun, Jini developers, so the use of
his computer would indicate something that he worked on creating I'd
guess.
Gregg Wonderly
On Oct 21, 2010, at 9:18 AM, Patricia Shanahan wrote:
Jonathan Costers wrote:
If we can get these cleared up, I believe we have a solid test
base in place to start validating some new developments and
experiments.
I have a few remaining test-related concerns:
1. Tests with multiple computers. This may be what "resendes" is
about. Surely many Apache projects need this for testing, so the
infrastructure should have some way of applying multiple virtual
computers for a single test.
2. Skipped tests. The category suppression suggests to me that
River, or maybe Jini before it, went through a phase in which the
developers took a "shoot the messenger" approach to test failures.
If so, some of the skipped tests could be valid tests that, if run,
would tell us something we need to hear. Once I've done with
failures that are preventing whole categories from running, I want
to review the skipped tests to make sure each skip is commented
with a better reason than the test failing.
3. Lack of effective testing of concurrency and retry behavior in
JoinManager and ServiceDiscoveryManager. I did start looking at
building a mock environment around SDM for the purpose of forcing
high traffic and difficult combinations of actions. Once we have
all the existing tests running, I'm going to take another look at
how effectively these difficult and important classes are being
tested.
Patricia
