Okay so i'm not sure what i'm doing wrong but i have my project setup like this:
Top level package/
Feature package that contains one feature file/
Page package that contains one page class/
Steps package that contains one step page./
Utils package that contains runner class and a "hook" class + a class that just contains a web driver that gets passed around.
in the Hook class i have method annotated with #Before. Now if i go into the feature file right click on a scenario and run it, the method in the hook class gets called np and everything is well.
If i go into my runner class and run the test from there, the method doesn't get called and the step methods in the Step class are being called first.
If i put a #Before method in the Step class this works fine, but i don't wanna duplicate my code, how do i work around this?
Edit: sorry i'm not sure why my indentation looks horrible.
Related
This question is about using Visual Studio 2019 for building an out-of-process COM server using ATL. (I have done this before in Borland but this is my first time using MSVC).
I created a project called MyObjectsProject with ATL Project wizard. This created the module class CMyObjectsProjectModule : public ATL::CAtlExeModuleT<CMyObjectsProjectModule> in file MyObjectsProject.cpp .
Then I added a simple object MyObject via "Add > ATL Simple Object" as described in the documentation . This created files MyObject.cpp and MyObject.h containing an interface IMyObject and CoClass CMyObject. So far so good.
I go to IMyObject in the Class View, and right-click "Add > Method" and give it some details, then it adds the method declaration to CMyObject in MyObject.h and an empty definition to MyObject.cpp as CMyObject::method_name() . So far, so good (again).
However at the same time, it added the method declaration and definition to MyObjectsProject.cpp as a class member of CMyObjectsProjectModule. Furthermore:
The CMyObjectsProjectModule::method_name() version is never called -- when I use the COM server via a client, and call IMyObject::method_name() on an instance of MyObject, it executes the version defined as CMyObject::method_name() as expected.
I can delete the method declaration and definition from CMyObjectsProjectModule and there are no errors.
The same thing happens if adding a Property. Also, the "Completing operation..." takes about 45-50 seconds to run.
My question is: What is the reason behind the method being added to the Module as well as to the CoClass , and when would that version of the Method be called? (Or is this just a bug and it is not supposed to be added to the module at all?)
In the Borland IDE , the similar function wouldn't add methods to the Module.
EDIT: Originally posted the question with the project called MyProject , however the problem only occurs when the project is called MyObjectsProject . I used different names in the question originally from what I observed the problem with, but have now edited the question and reproduced using the exact names in the question.
The method is not supposed to be added to the Module, and it is not supposed to take 45-50 seconds to add the method.
The problem seems to occur whenever the CoClass name is an initial substring of the Module name.
For example it occurs for CMyObject with module CMyObjectsProjectModule, but does not occur for CMyObject with a module of CMyProjectModule.
When the problem is occurring, the Class View for CMyObject > Derived Types > shows derived types CMyObject and CMyObjectsProjectModule.
I guess it is "deducing" a derived type relationship between two types where one is an initial substring of the other; and furthermore, that the behaviour of the "Add Method" decides to add the method to everything that it thinks is a derived type of the CoClass having the method added to.
Conclusion: This seems to be a bug (or at least, questionable design) in the IDE; and to work around it, you can rename the Module to begin with some unique substring such that none of the CoClasses will coincide with initial substrings of the Module.
The Class Designer tool does not show the two types as derived (i.e. that tool doesn't appear to use the same heuristic as the Class View window does for deciding if one type is derived from another)
I created functions(methods)in step1 using groovy in soapUI(open source) and calling in step2, it is not getting called, It is getting called only to that step1. I want to make those functions as global. can any one suggest me how to do that?
In order to achieve, what you are looking for is, to do the following:
Create classes (either in groovy or java of your preferred language)
Add the reusable methods into those classes
Compile the classes and create jar file
Copy the jar under SOAPUI_HOME/bin/ext directory
Restart the soapui tool
Now you should be able to call the reusable method from any of your project /test suite / test case/ test step.
Hope this is useful.
I have IntelliJ 12 and some groovy code (along with a pile of java code) in a project.
In intelliJ, i can see class A's import of some groovy code, and i have also included the library that has that code.
However, while the package itself is in one colour (for the import), the actual class being imported is in red, which implies an issue of some sort. Hovering the mouse over it reveals no issue though.
When i run a "make" or a "rebuild project" is where the problems start - i get
Groovyc: unable to resolve class com.blah.blah.blah.A
How can i resolve this?
Currently, my project setup is like so:
Under "Libraries" in (Project Structure -> Project Settings -> Libraries) I have:
the jar file with all the groovy code
the src jar file with all the groovy code
In the "Modules" section i have the - well, i don't know what to call it, the column isn't labelled - the library name from the libraries section associated with the src and class files, and the little "export" button beside it is ticked.
Incidentally, opening the class in intelliJ never shows the source code, which given the source is included struck me as weird.
Is there anything else I should need to do?
I've worked this one out, but if anybody knows why groovy cannot be in the "Resource Patterns" list and wants an upvote, do chime in
Oh, right.
I removed the !?*.groovy entry from the list of, um, entries in the File : Settings -> Compiler -> Resource Patterns thingy.
It doesn't seem to matter if "use external build" is on or off for this, but the !?*.groovy; entry cannot be there.
I wonder if anybody knows why?
I had the same problem and had to Add Framework Support and add Groovy to the project to get round this problem.
I created the project using gradle.
I just got your question in my Google results as I had a similar issue. My problem was that I was able to get the groovy code in my IntelliJ 12 project to compile ok, but it wasn't getting wired in properly when I tried to run unit tests within the IDE.
After some investigation, I uncovered that groovy and logback libraries were all set up in the project to be available in the runtime stage of the Maven build of the project, but that resulted in them not being available in the test stage. To fix this, I ended up manually updating the groovy-all and the logback libraries scope from runtime to provided under File->Project Structure->Modules->Dependencies. This allowed me to both compile and test within the IDE while including the Groovy modules as well as the Java modules.
Perhaps you had something similar going on in your project?
Six years later, I also just got this question near the top of my search results.
In my project my Unable to load class 'groovy.text.SimpleTemplateEngine' problem was actually due to a codenarc issue. I was able to resolve the issue by adding the following to build.gradle:
// codenarc version issue work-around
configurations.codenarc {
resolutionStrategy.eachDependency { DependencyResolveDetails d ->
if (d.requested.group == 'org.codehaus.groovy') {
d.useVersion '2.4.7'
}
}
}
I have two groovy files (in case you are not familiar with groovy, think of it as a java file).
I have file A.groovy in package test.BI. This file has makes use of a class Master which is in B.groovy which is also in the package test.BI. However this B.groovy also makes use of a class Execution which is in A.groovy.
When I compile A.groovy it errors unable to resolve class Master and when I compile B.groovy it errors unable to resolve class Execution.
Both A.groovy & B.groovy have multiple classes. How can I solve this problem without creating one file for each class.
In IntelliJ IDEA, invoke Make (Ctrl+F9), or Compile (Ctrl+Shift+F9) on just these two files (after selecting them both in the Project View).
I'm having trouble trying to run jython code embedded in a compiled groovy application. The same jython code works fine when it is embedded in a java application (The Grinder 3.1)
In the groovy code I use the org.python.util.PythonInterpreter class (from jython 2.2.1) to create a callable instance of a class called TestRunner (this is a requirement from The Grinder).
Illustrative jython code example:
class TestRunner:
def __init__(self):
doinitstuff()
def __call__():
a = A()
a.work()
class A:
def __init__(self):
self.b = B()
def work(self):
print "Calling methodcall"
self.b.methodcall()
class B:
def __init__(self):
self.webservice = WebServiceStubImplementedInJava()
print str(self.webservice)
def methodcall(self):
print "In methodcall"
try:
return self.webservice.soapmethod()
except:
log_error()
raise
Here is the output when I run the above code:
The TestRunners __call__() method will invoke the work() method of a class A instance, and the webservice stub's toString output is printed.
The "Calling methodcall" message is printed.
The "In methodcall" message is never printed, and instead I get: AttributeError: 'javainstance' object has no attribute '__call__'. The stacktrace ends with self.b.methodcall()
Do you have any idea why the invocation of self.b.methodcall() should result in AttributeError: 'javainstance' object has no attribute __call__
Adding some context to the problem...
I'm trying to use a Groovy class to execute the work that a Grinder worker thread would perform when we performance test our product.
I use groovy just for the sake of "less verbose code", but might have to switch over to plain old java if it's groovy that causes the problem.
The reason for doing this is that I need to find out which files are actually used by Grinder for a given test scenario.
We have hundreds of *.py files and configuration files etc, but only a subset of them are used for one specific test scenario. All of them are used in some test scenario.
This makes it quite hard for a "beginner" to understand how to configure a test so I'm trying to build a "test configurator wizard" that set up a test scenario without forcing the user/tester to edit all config files manually.
This wizard will collect the relevant files from a "repository" and put them in a folder where the "Grinder Console" can present them to the user.
So, the way I use to find out which files are used by Grinder is to use AOP (AspectJ) to capture all calls to java.io.FileInputStream(java.io.File) from any code in the org.python.util and org.python.core packages.
The "advice" I apply to these join-points is to print the file name to System.out.
I use load-time weaving for this, so I can run the groovy/java/jython code with our without
AOP enabled. The AttributeErrorproblem occurs regardless if I have AOP enabled or not.
I have a vague suspicion that the AttributeError problem could be caused by some classloader mismatch when a "groovy" class executes the PythonInterpreter methods, but I'm far from sure about this.
I'm not sure if groovy is doing any kind of runtime bytecode editing when it loads classes and if that confuses the PythonInterpreter.
The groovy code itself is precompiled so I use the regular java.exe to launch the process.