Community
Participate
Working Groups
We need to keep tests out of production plugin projects. They should go in a parallel project instead -- in some cases these projects already exist. Also, we should not have a dependency on junit4, that will definitely cause issues at build time.
Also, please note that we should not be using Manifest dependencies directly. Use the JUnit libraries instead. This means that you can only have one version of Junit at a time. I'm fine with Junit4 but you'll need to converr existing tests first. Let me know when you have the tests projects created -- they should go in the "tests" directories -- and I'll add any new projects to the tests feature so they'll get in our automated tests.
Moved tests from amp.axf.ide to amp.axf.ide.test. Removed JUnit dependency. Changed JUnit to version 4.
I think there are still some other tests I need to move...
Yep, sorry. I think in AGF core as well. You'll have to create a new test project for that. Just use the existing AXF one as a template and put it in the "tests" dir.
I've gone ahead and created the agf tests and moved the axf test so be sure to grab latest before committing anything else.
Please don't work on bugs that are assigned to me. Actually, I had already done that but wasn't ready to commit. As you know that merging with git is kind of a PINTA.
(In reply to comment #6) > Please don't work on bugs that are assigned to me. Actually, I had already done > that but wasn't ready to commit. As you know that merging with git is kind of a > PINTA. Oops! Sorry.
Not a problem. I've merged it all into mine and committed that. To make things simple, I think we should agree on a common strategy to structure test classes. Here comes my proposal (sorry, I've already applied it on the current commit - but let's change it back to something else if we find a better solution): 1. Keep the basic file tree like it is now: * org.eclipse.amp '- AGF, AMF, AXF or Escape |- features |- plugins '- tests 2. SWT-Bot or JUnit tests are put into a __fragment__ in the "tests/" directory, named exactly like the plugin to be tested. Just with the extension ".test". Example: The plugin "com.me.myplugin" in directory "plugins/" needs to be tested. The fragment that tests it should be called "com.me.myplugin.test" and is located under "tests/". 3. In the fragment that tests a plugin, org.junit (4.8.1) will be included as dependency. 4. Java source files will be put into the "src/" directory of the fragment (default). 5. To be able to use package visibility, class or method tests are put into the same package like the class under test. Example: I'm testing the class "com.me.ui.MyView". The class that tests is called "com.me.ui.MyViewTest" and remains in the testing fragment in the "src/" directory. Just as a hint: The "moreUnit" plugin automates a great deal of tasks when maintaining or writing tests. It also provides automated refactoring! Comments, changes, additions? Please.
Ooops. There are some fragments I've forgotten to change. Committing these changes now. Miles, there are some tests that used to fail before and still fail on my machine: org.eclipse.amp.axf.ide.test.TestExecutionTest org.eclipse.amp.axf.ide.test.ParameterExecutionTest org.metaabm.tests.SStyle3DTest org.metaabm.tests.SStyle2DTest
(In reply to comment #9) > Ooops. There are some fragments I've forgotten to change. Committing these > changes now. > > Miles, there are some tests that used to fail before and still fail on my > machine: Never mind these two, just found out why: > org.eclipse.amp.axf.ide.test.TestExecutionTest > org.eclipse.amp.axf.ide.test.ParameterExecutionTest But these two still end with an AssertionError: > org.metaabm.tests.SStyle3DTest > org.metaabm.tests.SStyle2DTest
Yes, sounds perfect to me. My only concern is with the fragments. I've had such a hassle getting the builds working that I'm afraid of doing anything that might mess that up. So let's go ahead and try the fragment approach and then revert to plain plugins if necessary. (In reply to comment #8) > 3. > In the fragment that tests a plugin, org.junit (4.8.1) will be included as > dependency. I think we still have some 3.8.2 tests hanging around. BTW, I haven't been able to get an application IDE build working because of some annoying JDT related junit issues so that's why I was mucking about with it yesterday. I'm having to experiment and the only way to test things is to commit the changes for a full build. I won't touch that stuff again though until you're done. > 4. > Java source files will be put into the "src/" directory of the fragment > (default). Exactly. > 5. > To be able to use package visibility, class or method tests are put into the > same package like the class under test. > Example: > I'm testing the class "com.me.ui.MyView". The class that tests is called > "com.me.ui.MyViewTest" and remains in the testing fragment in the "src/" > directory. Yes, that's a very good approach. > Just as a hint: > The "moreUnit" plugin automates a great deal of tasks when maintaining or > writing tests. It also provides automated refactoring! I'm assuming that that doesn't create any additional runtime dependencies? If I had my way I'd be using TestNG -- IMO it's a much more modern, flexible testing environment. For one thing it doesn't rely on all of those ugly statics which prevent you from doing much in the way of really dynamic testing. BTW, I don't think the SWTBot tests are functioning that well. We don't have them set up for automated testing right now. Do they work on your end?
(In reply to comment #10) > (In reply to comment #9) > But these two still end with an AssertionError: > > org.metaabm.tests.SStyle3DTest > > org.metaabm.tests.SStyle2DTest THey work fine on my machine and by definition they're working in automated build or the build would be failing. What are you seeing? BTW, this is probably obvious, but we really can't change that much in the structure of the metaabm/acore tests because those are auto-generated from EMF.
