I encountered an unfortunate aspect of Spock Framework (1.3-groovy-2.5), which I use for integration testing of a Gradle plugin.
The code sample
Parent class:
class ClassA extends Specification {
def setupSpec() {
System.out.println("In ClassA setupSpec()")
}
def "base feature"() {
expect:
true
}
}
Child class:
class ClassB extends ClassA {
#Override
def setupSpec() {
System.out.println("In ClassB setupSpec()")
}
def "extended feature"() {
expect:
true
}
}
When I run tests in ClassB, both versions of setupSpec() are called:
In ClassA setupSpec()
In ClassB setupSpec()
Of course, if I call method via native Groovy ways:
class Main {
static void main(String[] args) {
ClassB classB = new ClassB()
classB.setupSpec()
}
}
Then I see only what is expected:
In ClassB setupSpec()
So, evidently, this is a Spock feature of some kind.
Question
In practice, what is the suggested way of inheriting from implementations of Specification while overriding setup logic?
As documented in Fixture Method Invocation Order
If fixture methods are overridden in a specification subclass then
setup() of the superclass will run before setup() of the subclass.
cleanup() works in reverse order, that is cleanup() of the subclass
will execute before cleanup() of the superclass. setupSpec() and
cleanupSpec() behave in the same way. There is no need to explicitly
call super.setup() or super.cleanup() as Spock will automatically find
and execute fixture methods at all levels in an inheritance hierarchy.
The easiest way would be to just move the logic to another method that you can override.
class Base extends Specification {
def setupSpec() {
init()
}
def init() {
println "foo"
}
def "let's try this!"() {
expect:
Math.max(1, 2) == 2
}
}
class Sub extends Base {
#Override
def init() {
println "bar"
}
}
As documented, fixture methods are not meant to override each other but to complement each other, i.e. they are all called in a specific, logical order. Like you said, this is a feature.
Hence, my answer is: There is no suggested way to override setup logic. Instead, the suggested way is to design your base and derived specifications in such a way that overriding is not necessary. I never had any problems to do so and hope you shall solve your problem easily too.
Your sample code is too schematic to say anything more, but basically think about fixture methods in base classes as responsible for to setting up and cleaning up fixture fields in there, while derived specs' fixture methods would take care of additional fixtures specific to those classes. In your example there also is a feature method in the base spec, which I find rather strange because it would be executed for the base spec itself and each time a derived spec is executed. I rather like to think of base specs as practically abstract (avoiding to add any feature methods to them and them being picked up by the test runner), but I am sure there are cases in which what you sketched above might also be helpful. I just cannot think of one now.
Related
The Code A is from the project android/architecture-components-samples.
The author place the code of instance a class DefaultServiceLocator in the interface ServiceLocator.
In my mind , normally a interface should not include any implement code.
Is it a good idea to place the code of instance a class in a interface in Kotlin?
Code A
interface ServiceLocator {
companion object {
private val LOCK = Any()
private var instance: ServiceLocator? = null
fun instance(context: Context): ServiceLocator {
synchronized(LOCK) {
if (instance == null) {
instance = DefaultServiceLocator(
app = context.applicationContext as Application,
useInMemoryDb = false)
}
return instance!!
}
}
/**
* Allows tests to replace the default implementations.
*/
#VisibleForTesting
fun swap(locator: ServiceLocator) {
instance = locator
}
}
...
}
open class DefaultServiceLocator(val app: Application, val useInMemoryDb: Boolean) : ServiceLocator {
...
}
In my mind , normally a interface should not include any implement code.
Welcome back from hibernation ;) Yes, you could achieve the same with interface + abstract class but you can have default implementation also as part of the interface for some time now in many languages. Which way you go is up to you, but if you have only one abstract class implementing your interface then it is often handy to be able to merge this into one file for sake of ease of future maintenance.
As per kotlin interfaces documentation:
Interfaces in Kotlin can contain declarations of abstract methods, as well as method implementations. What makes them different from abstract classes is that interfaces cannot store state. They can have properties but these need to be abstract or to provide accessor implementations.
So... there's no problem in using method implementations on the interfaces. That feature might offer you extra power (if you like and need to use it).
I'd like to implement some interface methods in another file, using extensions.
I have a feeling it's not possible, but I'd love to do that.
Is this possible?
Here is the idea :
MyClass.kt
class MyClass : MyInterface {
}
MyClassExtension.kt
override MyClass.MyInterface.method1() {
}
override MyClass.MyInterface.method2() {
}
That is not possible to implement the interface in the other file. There are still some possibilities.
You may split your implementation into several abstract classes, e.g. abstract class A : Interface, abstract class B : A and so on. Each class can be in its own file.
The second alternative, that does not let one implement an interface, rather split method implementations is called extension functions.
https://kotlinlang.org/docs/reference/extensions.html
Extension functions are only able to access public API of a class. Extension functions cannot implement interface methods in that case.
Use the following syntax for the declaration:
fun MyClass.method2() { ... }
From what I understand gmock (and I'm new to it) EXPECT_CALL allows for specifying how a method will behave when it's called (in this case I'm mostly interested in what it will return). But I could just as well define the method explicitly with its body. Example:
class Factory
{
int createSomething();
};
class MockFactory : public Factory
{
MOCK_METHOD0(createSomething, int());
};
int main()
{
...
int something(5);
MockFactory mockFactory;
EXPECT_CALL(mockFactory, createSomething()).WillRepeatedly(Return(something));
...
}
vs
class MockFactory : public Factory
{
int createSomething()
{
return 5;
}
};
Now, if createSomething were to behave differently (return different things) in different scenarios then obviously I should use EXPECT_CALL. But if it's going to always return the same thing wouldn't it be better to just explicitly define the method's body? (Note that other methods in the mocked class might still use EXPECT_CALL.)
When you define a method you miss all the flexibility that mocking that method can give you in the tests.
If you need to assert in a test that createSomething gets called, you can only do it if you have mocked it, not if you have a standard method definition. Not in this case, but in case of methods taking parameters, it's even better to have a mock.
If you need to set up a default action that your method should perform, even when you don't set any expectations on it, do so using ON_CALL macro in the SetUp member function of a TestFixture.
Trait delegation is described in docs, and there are no questions. But what about class delegation?
class FrameWorkClass // Third party class we cannot modify
class MyDerivedFrameWorkClass(c:FrameWorkClass) : FrameWorkClass by c
What is the best way to achieve this without modifying FrameWorkClass? Obviously we are unable to make it implement our interface.
You can only delegate an interface to a variable that implements that interface. You cannot delegate directly to another class. As #Damian was pointing out; basically is simplified as:
interface Framework {}
class FrameWorkImpl: Framework {}
class MyDerivedFrameWorkClass(val fw: FrameWorkImpl) : Framework by fw {}
Or you can generically say:
class MyDerivedFrameWorkClass(val fw: Framework) : Framework by fw {}
to accept any implementation of the Framework interface and delegate to it, so FrameworkImpl and FrameworkHappyDays both work if they implement the Framework interface.
This is updated to current Kotlin, where trait has been renamed to interface
At the moment only traits can be delegated like this. If you have a class that you would like to delegate, I would simply take that class and extract a trait(interface) including all the methods you are interested in. Here is an example based on your code.
Imagine you have these classes:
class FrameWorkClass {
fun foo() {}
fun boo() {}
}
class MyDerivedFrameWorkClass(c:FrameWorkClass) : FrameWorkClass by c
It does not compile right? Let's say you are interested in foo()
trait FrameWorkTrait {
fun foo() {}
}
class FrameWorkClassImpl: FrameWorkTrait {
override fun foo() {}
fun boo() {}
}
class MyDerivedFrameWorkClass(c:FrameWorkTrait) : FrameWorkTrait by c
At least this is how I would do it.
I thought I've understood Spock interactions but I have to admin that I'm still missing some pieces of the picture.
Alright, here my problem: I have a method in a Grails service which performs some operations, including a call to a void method of the same service class. Here's the code:
class myService {
void myStuff(def myObj, params) {
// do my stuff
anotherMethod(myObj)
//do my stuff again
}
void anotherMethod(myObj) {
// do other stuff
}
}
I want to be sure that myStuff method calls anotherMethod, to test and document the correct behaviour.
So, here's the test in my Spock Specification class:
void 'test myStuff method'() {
given: 'my object and some params'
// doesn't really matter what I'm doing here
MyObject myObj = new MyObject()
params = [title: 'my object']
when: 'we call myStuff()'
service.myStuff(myObj, params)
then: 'anotherMethod() is called exactly one times'
1 * service.anotherMethod(myObj)
}
}
The error I get is:
Too few invocations for:
1 * service.anotherMethod(myObj) (0 invocations)
What do you think? What's wrong?
As always, thanks in advance.
You are asking for a very special, and generally discouraged, form of mock called partial mocking where methods on the class under test are mocked. Spock supports this since 0.7, but you'll have to create a Spy() rather than a Mock(). Also note that you cannot mock private methods. For more information on spies, see the reference documentation.