if you really have need of testing the logging you could try https://projects.lidalia.org.uk/slf4j-test/
8 replies
Another alternative would be to implement the
Logger interface and provide a delegating logger, something similar to LoggerWrapper, but with a non-final delegate and a setter for updating it. Then in each iteration you could set the new Spock mock as a delegate and then verify interactions on it without using detached mocks or shared fields. Sometimes doing a little bit of development work for a custom mock is better than pulling new dependencies into your project just for testing one thing. The mockStatic would return the delegating wrapper, of course.
16 replies
A good IDE like IntelliJ IDEA can automatically create all methods necessary for a delegate. Or maybe a Groovy
@Delegate would be even better, I didn't really think it through and/or try. In my time zone I am about to start dinner. But it would be interesting to try later.
@sevenlist Maybe just refactor your ClassThatLogs into
class ClassThatLogs {
private static final Logger LOG_INSTANCE = LoggerFactory.getLogger(ClassThatLogs.class);
private final Logger log;
ClassThatLogs() {
log = LOG_INSTANCE;
}
ClassThatLogs(Logger logger) {
log = logger;
}
}And just use the constructor to inject your mocked logger and just use log instead of LOG_INSTANCE in the class.
If you don't want to expose it in the constructor you could also use groovys ability to access private fields.
class ClassThatLogs {
private static final Logger LOG_INSTANCE = LoggerFactory.getLogger(ClassThatLogs.class);
private Logger log = LOG_INSTANCE;
}To modify the log field from the spec.
IMHO this is much a much cleaner approach then the other variants.
Static fields are always difficult to test, but it is kind of a standard pattern for loggers. Some people might not even use it (the pattern) intentionally, adding loggers via Lombok or Groovy transformations. Either way, adding an additional non-static logger field just for injectability from tests, while working nicely of course, looks super ugly IMO - especially if you have to do it in many classes. I think the perfect solution does not exist, like I just said in the other thread about my own too.
3 replies
Configuring the log framework to use a testable logger (like Björn said) is surely the cleanest way with regard to not having to use any dirty tricks or extend the application code just for tests, but of course then the tests are more like integration tests with regard to the log framework not being "mocked away".
hi guys, when I used Spock with SpringBoot to do Unit Test for Service layer. I got this error you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test
But when I saw some example online, they didn't do any special settings
https://twitter.com/spockframework/status/1377558567130107906
We have been advised of a copyright issue with the Spock name, to avoid future problems in this regard we have decided to rebrand. Henceforth, the Spock Framework will be renamed to GWT Framework (Given-When-Then).
Read the full announcement here https://spockframework.org/rebrand-announcement.html
I'm taking a class on Reactive Spring, and I've been able to use Spock no problem so far, but now there's a test using StepVerifier.withVirtualTime() and it passes no matter what. Here's the whole test:
def "With virtual time"() {
given:
VirtualTimeScheduler.getOrSet()
def longFlux = Flux.interval(Duration.ofSeconds(1))
.take(3)
.log()
expect:
StepVerifier.withVirtualTime({ longFlux.log() })
.expectSubscription()
.thenAwait(Duration.ofSeconds(3))
.expectNext(0L, 1L, 2L)
.verifyComplete()
}I also don't see the logs from the flux. Any ideas?
IIRC you need to create the flux inside the
withVirtualTime method, see https://www.baeldung.com/reactive-streams-step-verifier-test-publisher#3-testing-time-based-publishers as an example. Also you don't need VirtualTimeScheduler.getOrSet()AFAIK.
Is it possible to put Spock conditions in an external helper class and still get Spock to raise ConditionNotSatisfiedException? Any asserts i have in external helper methods just get treated like regular Groovy asserts.
class Testy extends Specification {
Helper helper = new Helper()
void "testy"() {
expect:
verify()
helper.verify()
}
void verify() {
assert 1 == 2
}
}
class Helper {
void verify() {
assert 1 == 3
}
}
If i make the external helper a closure, rather than a method, then it works just like a local method on Specification. Why is that?
class ClosureTest extends Specification {
Helper helper = new Helper()
void "testy"() {
expect:
verify.call()
}
}
class Helper {
Closure verify= { assert 1 == 2 }
}
What http client normally blends well with Spock website functional testing? I've looked at a few (httpbuilder, httpbuilder-ng) and I like their syntax (httpbuilder is nice) bit those projects are either abandoned or dormant. I'd like to use something actively support. thx
"i'm mostly using Spock for integration tests on apis" was a different user one message earlier
If you want browser tests, then sure Geb is the best choice for Spock.