1

Is it possible in cleanup method in Spock check is feature (or even better - current iteration of feature) passed or failed? In java's JUnit/TestNG/Cucumber it can be done in one line. But what about Spock?

I've found similar questions here:

Find the outcome/status of a test in Specification.cleanup()

Execute some action when Spock test fails

But both seems to be overcomplicated and it was years ago. Is there any better solution?

Thanks in advance

Update: main goal is to save screenshots and perform some additional actions for failed tests only in my geb/spock project

Varro
  • 73
  • 1
  • 11

1 Answers1

0

It is not over-complicated IMO, it is a flexible approach to hooking into events via listeners and extensions. The cleanup: block is there to clean up test fixtures, as the name implies. Reporting or other things based on the test result are to be done in a different way.

Having said that, the simple and short answer to your question is: This still is the canonical way to do that. By the way, you didn't tell us what you want to do with the test result in the clean-up block. This kind of thing - explaining how you want to do something but not explaining why (i.e. which problem you are trying to solve) is called the XY problem.

kriegaex
  • 63,017
  • 15
  • 111
  • 202
  • Maybe, I've just switched to these technologies from java and still use old java mindset. But anyway solution like `if(currentTest.isFailed)` seems to me much easier than creating extensions/listeners etc. Anyway I've updated start post with info that I need to save screenshots for failed tests. – Varro Mar 27 '20 at 13:06
  • 1
    Shouldn't Geb take screenshots automatically for each failed test? Just make the test extend `GebReportingSpec`. And what are "additional actions" only for failed tests? I cannot imagine. If it is so specific, an extension with corresponding interceptor(s) is a clean and re-useable way (across many tests or even projects) to do additional stuff. – kriegaex Mar 28 '20 at 07:46
  • Yes, GebReportingSpec saves page source and screenshot, but in my case it also required delete some test data just for failed tests (as in passed test it's already done). Anyway thanks for reply, I've got your point and pay more attention to extensions. – Varro Apr 13 '20 at 15:56
  • Like `try - catch` on the micro level, also on the this higher level you should put your resource clean-up into a `cleanup:` block or a `cleanup()` or `cleanupSpec()` method, depending on whether you want it to happen just for one feature method (FM), for all FMs or at the end of the specification. An artificial distinction of cases (passed vs. failed) is unnecessary. Just make sure the clean-up always happens. And if the resources have already been cleaned up, make the clean-up action handle that case gracefully. Very simple, no need to hook into the test life cycle and write extensions. – kriegaex Apr 14 '20 at 01:28
  • 1
    "An artificial distinction of cases (passed vs. failed) is unnecessary" - not sure that I fully understand this. As for me, passed/failed should be determined as my tests are data-dependent. Passed tests clean own test data themselves as a part of workflow. But failed tests can leave some data that should be removed. Hence it would be better to determine test result to perform cleanup or not. "Just make sure the clean-up always happens" - yes, I can perform cleanup for all result, but I just want to save time - no need to try to perform cleanup if passed test has already removed all test data – Varro Apr 16 '20 at 15:13
  • You don't get it, do you? You should not clean up resources inside the test but in a dedicated clean-up section or method after test execution. Then you don't do anything twice. But if you insist you can do it. Checking if something even needs to be cleaned up before doing so in the error case should not eat much time, the real clean-up action is what is expensive. Your idea to put this into an extension is generally a good one in case the extension can be used by many tests. But in this case as you described it, it sounds like bad design and over-engineered. Take my advice or reject it. – kriegaex Apr 17 '20 at 02:34
  • "You should not clean up resources inside the test but in a dedicated clean-up" - yes, for the most of cases I totally agree with you. But sometimes there are cases with removing data as a part of business logic - like "When I have permissions I am able to delete product". For passed test no need to perform any cleanup. But for failed ones - cleanup is required. And maybe I explain in not too detailed, but yes, this I plan to use this approach for many tests. Thanks for advices! – Varro Apr 17 '20 at 09:48