Hi Ulf,
On 29/03/2012 11:32 AM, Ulf Zibis wrote:
David, this is great news. You like my approach. :-)
I just want to reach closure ;-)
The separation in 3 files is intentional. I was thinking about of
reusing TestCollection for future tastcases on other methods of
AbstractCollection. But I'm not enough familiar with jtreg to argue, if
this is possible.
Similarly class Infrastructure could be reused over all JDK's tests. But
personnally I would prefer to more and more use the JUnit framework. Is
there already an existing example?
How do you ensure, that all existing jdk subclasses of
AbstractCollection are tested by the same patterns?
There are basically two sets of sets:
a) JCK tests: these are the official tests that should check that
classes meet their specifications. They live "elsewhere".
b) Other tests: these live in the source repository in the test
directory. These can combine additional "stress" tests, specific
regression tests for a given bug fix etc. These are jtreg based.
So here we are writing a regression test to be put in the repository and
executed using jtreg. I'm not an experienced jtreg user or test writer
so I can only look at other tests in the repository for guidance. But
these classes are not going to be part of some larger more general
all-encompassing test framework - at least not as part of this CR.
I like your javadoc for setSizeSequence, but I have an addition, see below.
Ok.
Have a nice flight,
Thanks, it's not quite imminent but I have a lot to do in the next
couple of days. :)
David
-Ulf
Am 29.03.2012 02:36, schrieb David Holmes:
Hi Ulf,
Thanks for the updates. This will take a little rearranging to get
into the right form I think - a single file is easier to deal with so
we could nest the TestCollection class.
Regarding setPseudoConcurrentChronologicalSizeSequence, I think perhaps:
/** Sets the values that size() will return on each use. The next
call to size will return sizes[0], then sizes[1] etc. This
allows us to emulate a concurrent change to the contents of
the collection without having to perform concurrent changes.
If sizes contains a larger valuethan on last invocation, the
collection will appear to
have shrunk when iterated; if a smaller value then the
collection will appear to have grown when iterated
*/
void setSizeSequence(int... sizes) {
this.sizes = sizes;
nextSize = 0;
}
Sean: can you massage this into a final version? If not I will try to
do so but I'm about to head out to JavaOne Japan and then am taking
some vacation time. Might be something I can work on on the plane :)
Thanks,
David
On 29/03/2012 4:48 AM, Ulf Zibis wrote:
Hi David, Sean,
I have made little changes to make understanding little easier, see
attachment...
-Ulf
Am 28.03.2012 07:29, schrieb David Holmes:
Hi Ulf,
I understand your point about ensuring we test
AbstractCollection.toArray but I find this revised test much harder to
understand.
Also in the name setPseudoConcurrentSizeCourse the word "Course"
doesn't fit. I'm not sure what you were meaning here? Perhaps just
modifySize or emulateConcurrentSizeChange ?
Thanks,
David
