Grails with Spock unit test + IntelliJ IDEA = No thread-bound request found

During my work with Grails project using Spock test in IntelliJ IDEA I’ve encountered this error: java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:131) at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.currentRequestAttributes(CommonWebApi.java:205) at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.getParams(CommonWebApi.java:65)... // and few more lines of stacktrace ;) It occurred when I tried to debug one of test from IDEA level. What is interesting, this error does not happen when I’m running all test using grails test-app for instance. So what was the issue? With little of reading and tip from Tomek Kalkosiński (http://refaktor.blogspot.com/) it turned out that our test was missing @TestFor annotation and adding it solved all problems. This annotation, according to Grails docs (link), indicates Spock what class is being tested and implicitly creates field with given type in test class. It is somehow strange as problematic test had explicitly and “manually” created field with proper controller type. Maybe there is a problem with mocking servlet requests?
During my work with Grails project using Spock test in IntelliJ IDEA I’ve encountered this error:
java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
 at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:131)
 at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.currentRequestAttributes(CommonWebApi.java:205)
 at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.getParams(CommonWebApi.java:65)
... // and few more lines of stacktrace ;)
It occurred when I tried to debug one of test from IDEA level. What is interesting, this error does not happen when I’m running all test using grails test-app for instance.
So what was the issue? With little of reading and tip from Tomek Kalkosiński (http://refaktor.blogspot.com/) it turned out that our test was missing @TestFor annotation and adding it solved all problems. This annotation, according to Grails docs (link), indicates Spock what class is being tested and implicitly creates field with given type in test class. It is somehow strange as problematic test had explicitly and “manually” created field with proper controller type. Maybe there is a problem with mocking servlet requests?
You May Also Like

Context menu or Action buttons ?

Recently I was drawn into one of those UI "religious" disputes that has no easy answers and usually both sides are right. One of our web developers was trying out new web tech (with pretty rich widget library) and started to question himself about some basic usability decisions. The low level problem in this case is usually brought to "which widget should I use ?". I'm not fond of bringing the usability problems to questions: Should I use Tabs over Menu ? Or should I use Context menu instead of buttons panel ? But sometimes if time is crucial factor and other usability levels are by default not addressed at all - better developer that asks those basic questions than developer that do not question himself at all.

Zabawy zespołowe: ćwiczenie głosu – RYBA!

Ćwiczenie ma za zadanie ośmielić osoby do mówienia głośno i wyraźnie. Ma też pomóc ustawić głos. Bardzo przydatne przy spotkaniach typu stand-up, gdzie "mruki" opowiadają pod nosem, co ostatnio robiły. Z mojego doświadczenia - działa!

Osoby biorące udział w ćwiczeniu stają w okręgu. Wybieramy sobie słówko do powtarzania. Proponowana jest ryba, ale może to być dowolne inne, proste w wymowie słowo.
Prowadzący ustala kierunek i jako pierwszy mówi szeptem ryba. Następnie, kolejne osoby powtarzają rybę, aż do donośnego"RYBA. Jeśli warunki pozwalają, można nawet krzyczeć, ale nie wrzeszczeć, bo wtedy wymowa jest niewyraźna. Po osiągnięciu maksymalnego (w pewnym sensie, ustalonego poziomu), zaczynamy ściszać głos, aż do szeptu. Naturalnie zabawę można powtórzyć dowolną ilość razy.

Jako szept warto przećwiczyć szept aktorski, czyli używanie szeptu, ale głośnego i wyraźnego, bez tembru głosu.

Mając jedno ustalone słowo, fajnie jest potem mobilizować kogoś kto mówi zbyt cicho wołając tylko "ryba!" i wtedy wszystko wiadomo.