I wanted to know where is the mapping of integration test classes done in Grails.
Actually I am trying to rename the default class to my application specific class, but when I am refactoring it then my test cases are not run.
Append Spec to your class name.
For example your class name is People then your class name should be PeopleSpec.
Here Spec for Specification in Spock
Related
I am working on a SilverStripe project. Project SilverStripe version is 4.4.4. In my project, I am trying to replace a class that injected for an interface. Both the interface and the class are part of the framework.
In the framework code, it has the following class
class NaturalFileIDHelper implements FileIDHelper
As you can see, the NaturalFileIDHelper is implementing the FileIDHelper interface. What I want to do is that I want to replace all the NaturalFileIDHelper instances with my customer class called CustomFileIDHelper class that is also implementing the FileIDHelper interface.
This is what I did.
I created a custom class called, CustomFileIDHelper that is implementing the FileIDHelper interface.
Then I added the following code snippet within the mysite.yml.
SilverStripe\Assets\FilenameParsing\FileIDHelper:
class: CustomFileIDHelper
Then I rebuild the project. But my project is still using the NaturalFileIDHelper class that comes with the framework. It seems like the CustomFileIDHelper class is not used.
How can I get it working? Is it possible to do that?
I want to replace all the NaturalFileIDHelper instances with my customer class called CustomFileIDHelper class
If you want to replace all NaturalFileIDHelper instances, then that's the class you should override (not the FileIDHelper). Also the .yml config you have needs to be passed to the Injector. (https://docs.silverstripe.org/en/4/developer_guides/extending/injector/)
SilverStripe\Core\Injector\Injector:
SilverStripe\Assets\FilenameParsing\NaturalFileIDHelper:
class: CustomFileIDHelper
But this will only work if the object is instantiated through the ClassName::create() function, and I found this piece of code in the framework:
(LegacyThumbnailMigrationHelper.php)
$defaultFileIDHelper = new NaturalFileIDHelper(), // Injector is not called here.
You will need to override the classes which call new NaturalFileIDHelper() and modify it to NaturalFileIDHelper::create(), you're able to call ::create() because the NaturalFileIDHelper class have the use Injectable; trait.
Also instead of going through the troubles of overriding classes which call new NaturalFileIDHelper(), you can create a pull request to the framework repository with your NaturalFileIDHelper::create() changes instead, as it would be an improvement to the current framework code (it enables the use of dependency injection).
I'm trying to create a new PHPUnit test class in PHPStorm. In the past when I've done this, when I fill in the Fully Qualified Name field with the class to test, the Test Class Name field would automatically update with
"class name" + Test.
But now, for some reason the IDE is not prepending the class name. Is there a setting I need to turn on? I'm following this guide and it says right on there that the default behavior
It appears that there was an issue in PHPStorm 2017.3.1 because once I updated to 2017.3.6, I no longer have the issue.
I want to do special functionality if I encounter a Kotlin class as compared to a generic Java class. How can I detect if it is a Kotlin class?
I was hoping that calling someClass.kotlin would throw an exception or fail if the class wasn't Kotlin. But it wraps Java classes just fine. Then I noticed that if I do someClass.kotlin.primaryConstructor it seems to be null for all java classes even if they have a default constructor, is that a good marker? But can that return null for a Kotlin class as well?
What is the best way to say "is this a Kotlin class?"
Kotlin adds an annotation to all of its classes, and you can safely check for its existence by name. This is an implementation detail and could change over time, but some key libraries use this annotation so it is likely to be ok indefinitely.
fun Class<*>.isKotlinClass(): Boolean {
return this.declaredAnnotations.any {
it.annotationClass.qualifiedName == "kotlin.Metadata"
}
}
Can be used as:
someClass.isKotlinClass()
The class kotlin.Metadata is not accessed directly because it is marked internal in the Kotlin runtime.
While the other answer may work (possibly outdated), many reflection features will not work on file classes or generated classes (lambdas, etc).
However, there is a parameter in the #Metadata annotation that can tell you if the class is what you are looking for:
A kind of the metadata this annotation encodes. Kotlin compiler recognizes the following kinds (see KotlinClassHeader.Kind):
1 Class
2 File
3 Synthetic class
4 Multi-file class facade
5 Multi-file class part
The class file with a kind not listed here is treated as a non-Kotlin file.
#get:JvmName("k")
val kind: Int = 1
We can take advantage of this to make sure we are only getting real classes:
val Class<*>.isKotlinClass get() = getAnnotation(Metadata::class.java)?.kind == 1
I can confirm this works in 1.6.20
I'm trying to use Groovy mixin transformation on a spring-mvc controller class but Spring does not pickup the request mapping from the mixed in class.
class Reporter {
#RequestMapping("report")
public String doReport() {
"report"
}
}
#Mixin(Reporter)
#Controller
#RequestMapping("/a")
class AController {
#RequestMapping("b")
public String doB() {
"b"
}
}
When this code is run .../a/b url is mapped and works but .../a/report is not mapped and returns HTTP 404. In debug mode, I can access doReport method on AController by duck typing.
This type of request mapping inheritance actually works with Java classes when extends is used; so why it does not work with Groovy's mixin? I'm guessing it's either that mixin transformation does not transfer annotations on the method or that spring's component scanner works before the mixin is processed. Either way, is there a groovier way to achieve this functionality (I don't want AController to extend Reporter for other reasons, so that's not an option) ?
You can find below the responses I got from Guillaume Laforge (Groovy project manager) in Groovy users mailing list.
Hi,
I haven't looked at Spring MVC's implementation, but I suspect that
it's using reflection to find the available methods. And "mixin"
adding methods dynamically, it's not something that's visible through
reflection.
We've had problems with #Mixin over the years, and it's implementation
is far from ideal and bug-ridden despite our efforts to fix it. It's
likely we're going to deprecate it soon, and introduce something like
static mixins or traits, which would then add methods "for real" in
the class, which means such methods like doReport() would be seen by a
framework like Spring MVC.
There are a couple initiatives in that area already, like a prototype
branch from Cédric and also something in Grails which does essentially
that (ie. adding "real" methods through an AST transformation).
Although no firm decision has been made there, it's something we'd
like to investigate and provide soon.
Now back to your question, perhaps you could investigate using
#Delegate? You'd add an #Delegate Reporter reporter property in your
controller class. I don't remember if #Delegate carries the
annotation, I haven't double checked, but if it does, that might be a
good solution for you in the short term.
Guillaume
Using the #Delegate transformation did not work on its own, so I needed another suggestion.
One more try... I recalled us speaking about carrying annotations for
delegated methods... and we actually did implement that already. It's
not on by default, so you have to activate it with a parameter for the
#Delegate annotation:
http://groovy.codehaus.org/gapi/groovy/lang/Delegate.html#methodAnnotations
Could you please try with #Delegate(methodAnnotations = true) ?
And the actual solution is:
class Reporter {
#RequestMapping("report")
public String doReport() {
"report"
}
}
#Controller
#RequestMapping("/a")
class AController {
#Delegate(methodAnnotations = true) private Reporter = new Reporter
#RequestMapping("b")
public String doB() {
"b"
}
}
When you map requests with annotations, what happens is that once the container is started, it scans the classpath, looks for annotated classes and methods, and builds the map internally, instead of you manually writing the deployment descriptor.
The scanner reads methods and annotations from the compiled .class files. Maybe Groovy mixins are implemented in such a way that they are resolved at runtime, so the scanner software can't find them in the compiled bytecode.
To solve this problem, you have to find a way to statically mixin code at compile time, so that the annotated method is actually written to the class file.
I have a couple of tests in my test suite being run in Zend_Test
One test creates a mock of Foo_Bar_Baz via PHPUnit's MockBuilder as that class its dependency. Now in the test for Foo_BAR_baz (the change in case is on purpose and is necessary due to autoloading), I am not getting the class but rather an instance of the mock, which obviously doesn't work.
Doing a var_dump on the object results in class Foo_Bar_Baz#27115(0) { } so it appears to be creating an instance of the mock.
Fixing the case of in the mock gets things to work as expected. I have never seen this behavior in mocking objects before. For some reason the mocked class is being loaded into PHP so that when the next test tries to instantiate the real object it instantiates the mock instead. Why would this be happening?
Class names in PHP are not case-sensitive, but filenames on a *nix server are.
I suspect the change in case is causing a change in behaviour because of an autoload mechanism; PHP would only autoload one of Foo_Bar_Baz.php and Foo_BAR_Baz.php.
In your case, if you have already defined a class Foo_BAR_Baz (as a mock) then PHP will use the same definition for Foo_Bar_Baz, thereby ignoring your real class definition.