Community
Participate
Working Groups
We have quite a few tests and some of them could be abstracted into a suite of tests to be ran by consumers on their own observable implementations. By exposing such a suite it would allow consumers to be certain of proper behavior while lessening the testing burden.
great idea!
++1++ :-)
I'm going to start prototyping this out in my spare time.
Created attachment 73801 [details] observable and observable value conformance tests I wanted to get your guys' feedback before I get deep into this. I've attached a patch, against HEAD, that contains conformance tests for observables and observable values. I've modified a few test cases to use these tests. When ran you'll see failures in ButtonObservableValueTestCase because there are bugs[1][2] in its implementation. The guidelines are: * The tests should be JUnit3 based. * The tests can only assert the conformance to the defined contract. * The tests should follow existing JUnit conventions to allow for integration into existing tests. * Each test should assert one outcome. * Assert message should be detailed defining the requirement being asserted. I'm using the parameterized test pattern that is found in JUnit Recipes[3] in order to make this happen. Each TestCase will need to create a setup() method that adds the appropriate conformance tests to a suite along with creating a delegate of the correct type. That's all that it takes. I'll try to find some time to make sure that this direction will work with JUnit4 as well. Any and all feedback is welcome. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=195603 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=196557 [3] http://www.manning.com/rainsberger/
I created a branch of the test project for this. Bug182059_investigation
(In reply to comment #4) > I'm using the parameterized test pattern that is found in JUnit Recipes[3] in > order to make this happen. Each TestCase will need to create a setup() method > that adds the appropriate conformance tests to a suite along with creating a > delegate of the correct type. That should be "a suite() method" and not "a setup() method".
Boris, I'd like to move these into a new project. I have implemented tests for IObservable, IObservableValue, IObservableCollection, and IObservableList. I have integrated these into some our tests but not all (we have well over 1,000 tests running now in the branch). Over time I'll be tweaking existing tests and writing others but I'd like to make these available to early adopters. During the course of 3.4 we'll be able to tweak these based upon feedback received. I was thinking of moving these into a org.eclipse.jface.databinding.tck project. I'm also working on documentation on the wiki. Let me know what you think on a new project.
The wiki page has been created. http://wiki.eclipse.org/JFace_Data_Binding/TCK
This is great, and should be very useful for extenders. McQ/Jeff, we would like to create a new test plug-in containing conformance tests for use in third-party tests, as well as our own data binding tests. An informal +1 from you would be good before I'll file a bugzilla to this effect against Community/CVS. As for the name, it seems that similar things are being called "test harness" elsewhere in Eclipse. Should the name of the new plug-in be: org.eclipse.core.tests.databinding.harness or is TCK more appropriate, e.g: org.eclipse.core.tests.databinding.tck
(In reply to comment #9) > As for the name, it seems that similar things are being called "test harness" > elsewhere in Eclipse. Should the name of the new plug-in be: > > org.eclipse.core.tests.databinding.harness > > or is TCK more appropriate, e.g: > > org.eclipse.core.tests.databinding.tck > I didn't use test harness because that has other implications. Maybe eventually we will provide test harness like capabilities. The current goal is to test the conformity of implementations thus TCK was used. But I don't have strong feelings either way and my guess is over time we'll be adding more test harness like capabilities. Also the reason I didn't put "core" in my recommendation is that we'd eventually add JFace dependencies along with others into the project.
(In reply to comment #9) > McQ/Jeff, we would like to create a new test plug-in containing conformance > tests for use in third-party tests, as well as our own data binding tests. An > informal +1 from you would be good before I'll file a bugzilla to this effect > against Community/CVS. Boris, did you send this to a mailing list or did you mean to add them to the bug?
(In reply to comment #10) > Also the reason I didn't put "core" in my recommendation is that we'd > eventually add JFace dependencies along with others into the project. Shouldn't we try to keep the conformance tests clean, so that others using it don't have to depend on JFace if all they do is (for example) implement observables for EMF?
oops - forgot to add to the cc list. (In reply to comment #9) > McQ/Jeff, we would like to create a new test plug-in containing conformance > tests for use in third-party tests, as well as our own data binding tests. An > informal +1 from you would be good before I'll file a bugzilla to this effect > against Community/CVS.
(In reply to comment #12) > (In reply to comment #10) > > Also the reason I didn't put "core" in my recommendation is that we'd > > eventually add JFace dependencies along with others into the project. > > Shouldn't we try to keep the conformance tests clean, so that others using it > don't have to depend on JFace if all they do is (for example) implement > observables for EMF? My hope was to get something out there for early adopters. Since we have all of 3.4, and I feel that it's pretty wide open as to what we might want to provide, creating one project and seeing what happens was my approach. I didn't want to have to create another project later with just 2 files that created a test harness for our jface support.
Comment on attachment 73801 [details] observable and observable value conformance tests See HEAD for the latest.
(In reply to comment #13) > oops - forgot to add to the cc list. > > (In reply to comment #9) > > McQ/Jeff, we would like to create a new test plug-in containing conformance > > tests for use in third-party tests, as well as our own data binding tests. An > > informal +1 from you would be good before I'll file a bugzilla to this effect > > against Community/CVS. > Has anything happened in regards to getting a project created?
Sorry, no. Boris is back in Canada next week, and we'll get it done then.
ping
I checked in tests for IObservableSets, added realm checking to the collection tests, and added a formatFail(...) method to build failure strings. When a test fails it now includes the TestCase class name and the name of the delegate. Without something in the fail message it's impossible to know what is failing when running the BindingTestSuite in Eclipse. I don't like having to do this and hopefully we can figure out something better. The only thing left to write are tests for IObservableMaps and to make sure all test cases are using the conformance tests. (In reply to comment #15) > (From update of attachment 73801 [details]) > See HEAD for the latest. > This is not in HEAD yet. That was a mistake. Everything's still in the Bug182059_investigation branch.
Sorry about the delay. I have filed bug 202657 for creating a new project org.eclipse.jface.tests.databinding.conformance (the name has been discussed with Brad, and we are both happy with it).
I've merged branch Bug182059_investigation to HEAD to minimize the merge effort.
Created attachment 78508 [details] Patch for new project Moves the conformance tests and test utilities into the conformance project. This will be applied after next weeks integration build.
Boris, when can I apply the patch? I remember there needing to be some coordination to do this.
Created attachment 79178 [details] patch to tests.databinding I applied the part of attachment 78508 [details] that applied to the new project as per our conversation (between Boris and myself). This patch contains the resulting changes to org.eclipse.jface.tests.databinding.
The test build was successful.
VERIFIED in I20071031-1800.
