I believe what Mario is saying is that you are comparing Apples to Oranges.
In your post, you compare Sets with List implementations; doing so, you are testing the implementation of classes with totally different contracts. If you compared different Set (like Hash and Tree) implementations, that's ok. If you compare different List (like ArrayList and Linked) implementations, that's ok too. If you compare Lists with Sets, then I don't know what you are testing.
Someone trained in programing will first choose the interface corresponding to his need. If order and indexed (numerical) access are important, then a List is appropriate. If locating the presence of an element is important, then you need a Set. From your requirements (storing and retrieving objects), I would bet that a Set should almost always win (if hash codes are good). About the test cases:
- TC1 is ok
- TC2 and TC3 do not test your requirements.
- TC4 is plain weird: you treat a List as a queue (ok, that's a way of looking at things). As for the Set test, I have no clue what you are testing. I would have expected the removal of a random element as order is uncalled for. What you do is unclear and seems artificial.
I think it's a good start (it actually reminds me of a programing assignment), but these tests require a bit more thought. and in its current state, they do not show anything interesting. I've got the following questions.
- Why do you not test specialised data structures if you want to consider parallelism? If I want to write a high performance multi-core app, I would probably need to use complex strategies to perform efficient synchronisation.
-Why do you use the iterator's remove() method? It's the first time I hear someone considering that it's a standard way of removing objects.