Hi Landon!
2012/1/22 Landon Blake sunburned.surve...@gmail.com
One of my challenges when trying to unit test parts of the OJ core
previously has been the number of inter-dependencies. Did you come up
with a mock or stub for WorkbenchContext? I really see some value in
sharing mocks and
Thanks for explaining Benjamin. I understand now. Smart move using
your framework to create the Workbench instance for testing. I will
need to check that out.
Landon
On Wed, Jan 25, 2012 at 7:57 AM, Benjamin Gudehus
hasteb...@googlemail.com wrote:
Hi Landon!
2012/1/22 Landon Blake
Yes, that's pretty good. I have some time in the next couple of days
to write some tests classes.
2012/1/26 Landon Blake sunburned.surve...@gmail.com
Thanks for explaining Benjamin. I understand now. Smart move using
your framework to create the Workbench instance for testing. I will
need to
Benjamin:
This has been a hard thread to follow, but it sounds like you've been
doing some good work on unit testing and reducing plug-in dependencies
in OpenJUMP.
You wrote: After a while I started to write unit tests and thus
needed to build a WorkbenchContext outside of OpenJUMP to run these
sorry for the late reply.
Yes I think its fine to commit this - unit tests are a good thing
(except I have never used them ;)
thanks
stefan
Am 11.01.12 19:37, schrieb Benjamin Gudehus:
I will then commit this into trunk.
2012/1/11 Benjamin Gudehus hasteb...@googlemail.com
thanks! hopefully i'll have time to play with it during the year. when it comes
to junit all i know is, it exists ;)
thx agn.. ede
On 13.01.2012 12:42, Benjamin Gudehus wrote:
Up and running!
2012/1/13 Stefan Steiniger sst...@geo.uzh.ch mailto:sst...@geo.uzh.ch
sorry for the late
On 10.01.2012 23:46, Michaël Michaud wrote:
If we want to directly commit this to trunk without creating a branch,
I first need to thunk about possible consequences when we refactor exising
code.
Stefan maybe has also some ideas about that.
Right, wait for Stefan's and Ede's advice.
It must
On 11.01.2012 18:20, Benjamin Gudehus wrote:
until now i understood the testing framework as an addition, isn't it?
The testing framework is just an additional package, yes. In order to run and
write tests on/for the plugins in the tools menu we don't need any
refactorings.
in
It must make use and adoption simple, not more complex !
+1
2012/1/11 edgar.sol...@web.de
the trunk is very reliable these days. i want to keep it that way.
can you explain what has to be refactored to what degree? changes to core
are especially delicate because we can easily break
in this case it is up to you whether to branch or not. as it is an
addition it will be easy to merge later, it's merely an organizational
decision.
regards ede
here are my steps:
0. create eclipse project (mvn eclipse:eclipse failed, so I created it via
eclipse, only add libs in /lib)
I will then commit this into trunk.
2012/1/11 Benjamin Gudehus hasteb...@googlemail.com
in this case it is up to you whether to branch or not. as it is an
addition it will be easy to merge later, it's merely an organizational
decision.
regards ede
here are my steps:
0. create eclipse
Hi Benjamin,
I've started to build the testing environment a week ago. Let's make
a brief summary about what happend since my last post.
Documentation was added to the classes and Javadocs and testing results
can be generated as html files. Also all needed methods for the tests
where
arranged
@Michaël
Nice to see your progress on a unit test framework setting.
It would be good if it could help making a better separation between
plugin parameters and ui stuff.
I think the other plugins should be refactored like you already refactored
the
UnionByAttributePlugIn.
Hi,
Yes, Stefan already added me to the developers list:
https://sourceforge.net/project/memberlist.php?group_id=118054
Fine,
The question is now, how to add the framework to the repository.
Adding it to the svn would be of course the best way to work together.
Sure,
I might create a new
Wouldn't be enough to add a new package to the source trunk for
developpers and to exclude the package for releases, and nightly builds ?
Michaël
Okay. I will relayout the existing source code to fit into the structure of
core/trunk.
After that I will create a new branch at svn with the
If we want to directly commit this to trunk without creating a branch,
I first need to thunk about possible consequences when we refactor exising
code.
Stefan maybe has also some ideas about that.
2012/1/10 Benjamin Gudehus hasteb...@googlemail.com
Wouldn't be enough to add a new package to the
Hi,
If we want to directly commit this to trunk without creating a branch,
I first need to thunk about possible consequences when we refactor
exising code.
Stefan maybe has also some ideas about that.
Right, wait for Stefan's and Ede's advice.
It must make use and adoption simple, not more
2. Legacy code and testing
How to test plugins (from the tools menu)?
(1) Create and setup a JUMPWorkbench with WorkbenchFrame and
WorkbenchContext. The method JUMPWorkbench.main() has all needed
instructions. In order to run the plugins we need to set
WorkbenchFrame visible. This is only
Here is an update:
I've finished point 2. Now it's possible to run unittests for
theUnionByAttributePlugIn.
Project page: https://github.com/hastebrot/openjump-tools-sandboxZip
file: https://github.com/hastebrot/openjump-tools-sandbox/zipball/master
Please grab the zip file and try it out. I've
Hei Benjamin,
thanks for your work. Its good that someone steps forwards with
introducing unit tests (finally).
Give us some time to read check things out.
stefan
Am 04.01.12 23:25, schrieb Benjamin Gudehus:
Sorry, the last post became badly formatted, so I post it again. Hope
this looks
Hi Benjamin,
It will take me some times to read carefully your proposals and test
your contributions.
I see many good ideas.
We have just to be careful because we are a small team with limited
experience, and OJ is quite a big project with a long history and much
legacy code hosted by the
@Stephan
Yes, and there is much work to be done :)
I'll document that code that we already have. To make it more easier to
start with unit testing.
@Michael
Yes, I think the new testing environment and the upcoming refactorings
should go into a svn branch.
Scripting/macros: That's how I
Hi Benjamin,
yup - what Ede describes is what I do too in Eclipse.
I have a OpenJUMP project that I setup and run without any addons (but
using the default-plugins option)
Then I have setup another Project that will contain my own code. As you
describe the PlugIn or is Extension class is where
On 03.01.2012 10:44, Stefan Steiniger wrote:
Its not truly dynamical and does not work for GUI changes, but for
algorithms (and when class variables inside the plugIn class don't
change) I can modify code live in Eclipse Debug Mode.
if i always recreate gui components (for testing) i can
@Michaël
Interesting. What kind of test ?
Three kinds of tests: (1) for the dialog using a GUI robot with FEST-Swing,
(2) for the plugin functionality and (3) for unittests of components used
by plugins. I write these tests BDD-style using Spock and Groovy and run
them with JUnit within Eclipse
On 03.01.2012 12:50, Benjamin Gudehus wrote:
@Ede
the intended way to develop extensions with plugins is afaik like this:
Ok, I stumpled upon the workbench-properties.xml when I made the list of all
plugins, but never used the xml file for my plugins, since I never use
FeatureInstaller
Happy new year!
I did some research on the refactoring of the PlugIns in the tools menu and
want to discuss some points:
1. Software development process
2. Legacy code and testing
3. Separation of GUI and code
Let's start with the first point, since I really like to know how you guys
27 matches
Mail list logo
