My definition of “testcase” here is one scenario example, or just a scenario if no examples are defined for the scenario.
That is, the number of testcases in a suit is the total number of times any scenario is executed. We have around 40 classes containing methods annotated as step implementations (@Given/@When/@Then). I have tried increasing (and decreasing) heap size in Eclipse. Since this is a 32-bit Windows system with only 3,5 GB ram, the possibilities are limited. 1GB max heap size is what I’m using. The lag (but not the hangs) is also reproducible in my home environment which is 64-bit with 16GB ram, 4GB heap size in Eclipse. Anyone willing to try this, just: 1. Unzip the attached file from my previous post, and create a project in Eclipse with the three classes. Set the source folder to src/main/java in Eclipse. 2. Generate the step classes and story files by running the GenerateStories class inside Eclipse 3. Refresh the project in Eclipse to make the generated files visible. 4. Open a story file and just type random characters in any existing steps. 5. Notice the lag when typing characters. Also note CPU usage while doing this. I’m using Eclipse 4.4, with JBehave plugin 1.0.0.20140605-0717 /Anders From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org] Sent: den 2 september 2014 13:04 To: dev@jbehave.codehaus.org Subject: Re: [jbehave-dev] Blocking problem with JBehave eclipse plugin and large project (1900 testcases) What is a testcase for you? How many steps classes do you have? You can add a debug logger level via the JBehave Preferences to see where the bottleneck is. BTW, Have you tried increasing the memory? On 1 Sep 2014, at 17:49, "Anders" < <mailto:codeh...@aek.se> codeh...@aek.se> wrote: The problem is that Eclipse becomes very slow and often hangs with a greyed out unresponsive GUI after that a story file or a step implementation file (Java file with Given/When/Then annotations) is edited. It is enough to type a few letters, no save required, for the unresponsiveness to start. We are using 32 bit Windows 7 for all developer work. (yes, it is just ridiculous that we are not allowed to use a 64 bit developer environment, so this is what we have to work with) Attached is a simple project that demonstrates the problem. Load this project up using Eclipse with the latest JBehave plugin, run the story generator, and then try to edit any story file or step implementation class, and enjoy the lag. Simply run the class GenerateStories to regenerate the stories and step implementation files. After this, refresh the project and it now contains 100 generated story files, each containing 10 scenarios with three steps each, and 100 step implementation classes / java files. The number of stories, scenarios and step implementation classes to be generated can be configured by changing the values of the constants below: public class GenerateStories { private final static String OUTPUT_PATH = "src/main/java/jbehave/stress"; private final static String STORIES_OUTPUT_PATH = OUTPUT_PATH + "/usecases"; private final static String STEPS_OUTPUT_PATH = OUTPUT_PATH + "/stepimpl"; private final static int NUMBER_OF_USECASES = 100; private final static int NUMBER_OF_STORIES_PER_USECASE = 10; private final static int NUMBER_OF_SCENARIOS_PER_STORY = 10; private final static int NUMBER_OF_STEP_IMPLS_PER_JAVAFILE = 100; // must be same or higher than NUMBER_OF_USECASES for all steps to resolve . . . The current situation in our project is unbearable due to this. We have 1900 test cases running each night, and continuously have to keep the tests updated and add new tests each and every day. Maybe if someone can do some profiling on the plugin, and publishing the results would help the community to overcome this. Please help. /Anders <JbehaveStress.zip> --------------------------------------------------------------------- To unsubscribe from this list, please visit: <http://xircles.codehaus.org/manage_email> http://xircles.codehaus.org/manage_email
