Add BlockListener support... #1575

leonard84 · 2023-02-16T18:56:24Z

This feature allows extension authors to register a IBlockListener for
a feature to observe the execution of a feature in more detail.
This surfaces some of Spock's idiosyncrasies, for example interaction
assertions are actually setup right before entering the preceding
when-block as well as being evaluated on leaving the when-block
before actually entering the then-block.

The only valid block description is a constant String, although some
users mistakenly try to use a dynamic GString. Using anything other
than a String, will be treated as a separate statement and thus ignored.

fixes #538
fixes #111

codecov · 2023-02-16T19:03:18Z

Codecov Report

Attention: Patch coverage is 85.12397% with 18 lines in your changes are missing coverage. Please review.

Project coverage is 81.87%. Comparing base (2c7db77) to head (d9b7e2e).
Report is 97 commits behind head on master.

❗ Current head d9b7e2e differs from pull request most recent head b16eac0

Please upload reports for the commit b16eac0 to get more accurate results.

Files	Patch %	Lines
...rg/spockframework/runtime/DataIteratorFactory.java	40.00%	9 Missing ⚠️
.../java/org/spockframework/runtime/ErrorContext.java	82.35%	3 Missing ⚠️
...main/java/org/spockframework/compiler/AstUtil.java	50.00%	2 Missing ⚠️
...ockframework/runtime/extension/IBlockListener.java	0.00%	2 Missing ⚠️
...java/org/spockframework/compiler/SpecRewriter.java	97.22%	0 Missing and 1 partial ⚠️
...org/spockframework/runtime/PlatformSpecRunner.java	75.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1575      +/-   ##
============================================
+ Coverage     80.44%   81.87%   +1.42%     
- Complexity     4337     4599     +262     
============================================
  Files           441      448       +7     
  Lines         13534    14428     +894     
  Branches       1707     1816     +109     
============================================
+ Hits          10888    11813     +925     
+ Misses         2008     1947      -61     
- Partials        638      668      +30

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

szpak · 2023-02-16T22:43:22Z

spock-core/src/main/java/org/spockframework/runtime/extension/IBlockListener.java

+import org.spockframework.runtime.model.IterationInfo;
+
+public interface IBlockListener {
+  void blockEntered(IterationInfo iterationInfo, BlockInfo blockInfo);


Seeing this PR, it brought back our discussion on Slack about a possibility to write a - much desired by me - extension "calling flush in database tests with rollback". I immediately, started to write a PoC which led me to a question, if there are use cases where blockExited() counterpart could be needed?

In the aforementioned example, placing a "flush call" at the end of the when block would be preferred. Otherwise, the extension would need to cover both then and expect blocks, which here should have similar effect (maybe a little more redundant 2x flush with a when..then..then construction).

Calling "something" after the then block, regardless it is the last then block or just the first one in the when..then..when..then sequence? It would be more tricky to handle with just blockEntered.

Do you see any glitches (e.g. with mocks) if blockExited would be also available?

~~Adding that method later would break backward compatibility and to not force people to implement it, blockExited could even have a default implementation (if blockEntered were preferred).~~

Update. A temporary mental block... Of course, with a default method, it would be possible to add that second method later. However, if there are no "implementation issues", I propose to have two methods and maybe also create AbstractBlockListener to do not force people to implement both of them, but only thatneeded.

I had thought about it and initially decided against it, as it was another method call added to every block.
The other thing I was unsure about was how to deal with exceptions, if we wanted to call blockExited even when an exception happened then that would require wrapping block in yet another try-catch, changing the variable scope.
That is why I ultimately decided against implementing it that way, you still have access to the error and block by using the IRunListener.error method with the newly enhanced currentBlock info.
When using the easy/elegant way to add the blockExited it surfaces some potentially undesirable interactions with other transforms.
Mainly with interaction validation, i.e. leaveScope() and the way thrown() will rewrite the AST, see the generated AST for details.
I've committed the change for review.

I haven't thought about the exception handling in the "blockExited" before, but definitely it complicates the situation. Good that you were able to solve it. I will try to play with it in my PoC extension, but I have other conceptional question before.

The extension is intended to call flush() on auto detected or specified field (e.g. EntityManager) in blockExisted. IBlockListener.blockExited() is called in the right moment, but to get a current state of the field, the IMethodInvocation is needed (for myfieldInfo.readValue(invocation.getInstance())).

Was it intended to add a block listener from a method execution interceptor or I misuse it?

//annotation driven extension class @Override public void visitSpecAnnotation(EnforceJpaSessionFlush annotation, SpecInfo spec) { FieldInfo entityManagerField = ... //just a simple case, no corner cases spec.getFeatures().forEach(methodInfo -> { //ignore features from super class for a moment methodInfo.addInterceptor(new AbstractMethodInterceptor() { @Override public void interceptFeatureExecution(IMethodInvocation invocation) throws Throwable { //also IterationExecution invocation.getFeature().addBlockListener(new IBlockListener() { @Override public void blockExited(IterationInfo iterationInfo, BlockInfo blockInfo) { if (blockInfo.getKind() == BlockKind.WHEN) { ... Object entityManager = entityManagerField.readValue(invocation.getInstance()); GroovyRuntimeUtil.invokeMethod(entityManager, "flush"); } } }); invocation.proceed(); } }); });

Currently, it is not really intended to be used that way, as this will not work properly when you adding a listener to a data-driven feature.

Good to know, I haven't checked the data-driven feature yet. Nevertheless, my use case with calling JPA flush after the when block perfectly matches BlockListener, so maybe you will figure our a way to make it work also with data-driven features :).

Well, we could just add the current instance to the arguments.

That would be some option (assuming it will be easy to get the execution context/instance in DeepBlockRewriter).

Btw, when I replaced interceptFeatureExecution with interceptIterationExecution it seems to work for both regular and data-driven features (originally I used both the interceptors as I thought the interceptIterationExecution is not called for regular features - as IRunListener.beforeIteration(), but it is and I had doubled execution). However, maybe there are some other (yet unknown for me) corner cases.

That would be some option (assuming it will be easy to get the execution context/instance in DeepBlockRewriter).

It would be just generating this as parameter.

The more basic question would be, should these block listeners perform any work than can throw an exception, and if so, should we handle it in any way, or just let it propagate?

I was mainly seeing these as tools for reporting, not doing stuff that affects the execution of the spec/feature.

My maybe not very helpful thoughts about this are: You can expect users to try to (ab)use the new block listeners in all ways possible, including ones unintended or even unimagined by you. The rest is documentation and error reporting. Just make any current limits transparent to users and maybe push them (the limits) further in a future release, if you think it makes sense. Of course, doing it right (whatever that means) in the first shot would also be nice.

I was mainly seeing these as tools for reporting, not doing stuff that affects the execution of the spec/feature.

Developers are creative :-).

Irregardless of the intentions, even in the reporting, there is a chance to end up with an unexpected exception. My first thought was to just to retrow it. The (filtered) stacktrace is not perfect, but in my opinion is readable enough - the extension failed in the "blockExited" method:

java.lang.RuntimeException: Unexpected during reporting at org.spockframework.boot2.EnforceJpaSessionFlushExtension$1$1.blockExited(EnforceJpaSessionFlushExtension.java:72) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at org.spockframework.boot2.EnforceJpaSessionFlushSpec.foo - parameterized(EnforceJpaSessionFlushSpec.groovy:50)

In general, I would say the accidental errors should rather be re-thrown.

Looking from my (possibly) extension point of view, the exception thrown in the listener should be considered the same way as exceptions thrown in regular statements in (for example) the "when" block - to control flow or anything else (e.g. "constraint violation" exception from the flush() in the blockExited for the when block, could be handled in by the thrown() section - as a regular "constraint violation"). I don't know, if it complicates the implementation.

Btw, you were right Leonard, the aforementioned yesterday construction doesn't work well with the parameterized feature. interceptIterationExecution() adds listener for every iteration and I end up with n listeners for n iterations which is not always desirable :). The listener cannot be created just for the first one, as the invocation in the second iteration would refer to the invocation from the first one. It should be possible to keep the reference of added listeners and remove former in the later iteration, but it's very inelegant and fragile :-/.

Update. AtomicBoolean per iteration/listener which allows for just a single listener execution (here for WHEN) works without the removal, but still, it is a workaround.

Update 2. Even better:

if (invocation.getIteration().getIterationIndex() != iterationInfo.getIterationIndex()) { return; }

but still, just a workaround.

kriegaex · 2023-02-17T10:35:00Z

Hi @leonard84. I cannot perform a formal code review, because I am not a committer, but I hope that during the weekend I can find a small time slice to build and play around with it. I simply wanted to say thanks in advance for taking care of this feature request. It has not gone unnoticed.

Quick question: Are you planning to add more commits to this PR? Code changes? User manual? I am just asking, not demanding anything. I simply do not want to start testing too early. As for the user manual, I can of course take a look at the unit tests and take it from there. But that might not be true for all future extension developers, I am just speaking for myself.

leonard84 · 2023-03-10T10:47:32Z

@kriegaex I'll write some documentation for it, but I mainly wanted to get feedback on the feature first, like the one from @szpak concerning the usability.

leonard84 · 2023-03-10T10:50:34Z

...ecs/src/test/groovy/org/spockframework/smoke/ast/condition/ExceptionConditionsAstSpec.groovy

+        try {
+            org.spockframework.runtime.SpockRuntime.callEnterBlock(this.getSpecificationContext(), new org.spockframework.runtime.model.BlockInfo(org.spockframework.runtime.model.BlockKind.WHEN, []))
+            foobar = this.foobar()
+            org.spockframework.runtime.SpockRuntime.callExitBlock(this.getSpecificationContext(), new org.spockframework.runtime.model.BlockInfo(org.spockframework.runtime.model.BlockKind.WHEN, []))


💬 this won't be called, fixing this makes for some awkward interactions between the individual AST transformations,

I tried moving the blockListener logic where the blocks are written back in SpecRewriter#L388, however this didn't work for some cases, e.g. cleanup as it already replaced all Blocks with an anonymous block.

spock-specs/src/test/groovy/org/spockframework/smoke/ast/mock/MocksAstSpec.groovy

spock-core/src/main/java/org/spockframework/runtime/model/ErrorInfo.java

szpak · 2023-03-13T17:19:12Z

spock-core/src/main/java/org/spockframework/runtime/extension/IBlockListener.java

+import org.spockframework.runtime.model.IterationInfo;
+
+public interface IBlockListener {
+  void blockEntered(IterationInfo iterationInfo, BlockInfo blockInfo);


Good to know, I haven't checked the data-driven feature yet. Nevertheless, my use case with calling JPA flush after the when block perfectly matches BlockListener, so maybe you will figure our a way to make it work also with data-driven features :).

szpak · 2023-10-02T15:42:21Z

As this PR seems a little bit stalled, I pushed the code I initially created ~6 months ago as a PoC for the BlockListener support. It a very raw version (with a lot of diagnostic stuff to be amended in the future), but functional in some basic scenarios. The JPA session, where requested, is flushed after the when block.

https://github.com/szpak/spock-jpa-flush-enforcer/tree/preview1

I would like to awake discussion about future shape of this PR.

@leonard84 @kriegaex WDYT?

leonard84 · 2023-10-06T14:23:29Z

It mostly hangs on the problems that adding the exit listener introduces #1575 (comment)

leonard84 · 2024-03-21T17:26:41Z

I think I've fixed the issues, but I need another fresh set of eyes to verify that everything looks good, I've stared at too many snapshots already.

spock-core/src/main/java/org/spockframework/runtime/ErrorContext.java

spock-core/src/main/java/org/spockframework/runtime/SpecificationContext.java

spock-core/src/main/java/org/spockframework/runtime/SpockRuntime.java

AndreasTu · 2024-03-21T18:36:06Z

spock-core/src/main/java/org/spockframework/runtime/SpockRuntime.java

+    context.setCurrentBlock(blockInfo);
+    List<IBlockListener> blockListeners = currentIteration.getFeature().getBlockListeners();
+    if (blockListeners.isEmpty()) return;
+    blockListeners.forEach(blockListener -> blockListener.blockEntered(currentIteration, blockInfo));


How about extract method notifyListeners:

void notifyListeners(IterationInfo currentIteration, Consumer<IBlockListener> code){ List<IBlockListener> blockListeners = currentIteration.getFeature().getBlockListeners(); if (blockListeners.isEmpty()) return; blockListeners.forEach(code); }

spock-core/src/main/java/org/spockframework/runtime/model/FeatureInfo.java

spock-core/src/main/java/org/spockframework/runtime/model/IErrorContext.java

spock-core/src/main/java/org/spockframework/runtime/ErrorContext.java

spock-core/src/main/java/org/spockframework/runtime/extension/IBlockListener.java

leonard84 · 2024-03-21T19:09:55Z

@AndreasTu, as I mentioned earlier, I'll write some documentation and polish it later. Thanks for your comments in any case.

However, I'm looking for a review of the correctness of the implementation and generated code and general usability.

szpak

I've switched my experimental (and heavily work-in-progress) extension to the latest version and it still works as expected without any modification. Nice.

I will think about the possible corner cases, I might encounter there.

Btw, I wonder, if it is still a recommended way to decide if the block listener was intended for the current iteration?

szpak · 2024-03-21T18:52:40Z

spock-core/src/main/java/org/spockframework/runtime/SpockRuntime.java

+    IterationInfo currentIteration = context.getCurrentIteration();
+    List<IBlockListener> blockListeners = currentIteration.getFeature().getBlockListeners();
+    if (blockListeners.isEmpty()) return;
+    blockListeners.forEach(blockListener -> blockListener.blockExited(currentIteration, blockInfo));


Is this ...isEmpty()) return; a kind of an "optimization" or we don't want to call forEach() for any other reason?

default void forEach(Consumer<? super T> action) { Objects.requireNonNull(action); for (T t : this) { action.accept(t); } }

spock-core/src/main/java/org/spockframework/runtime/extension/IBlockListener.java

spock-specs/src/test/groovy/org/spockframework/smoke/parameterization/DataProviders.groovy

spock-core/src/main/java/org/spockframework/runtime/model/BlockInfo.java

Vampire

Some things missing in multiple places:

license headers
JavaDoc
documentation
@Beta
@since

spock-core/src/main/java/org/spockframework/compiler/AstUtil.java

spock-core/src/main/java/org/spockframework/compiler/DeepBlockRewriter.java

spock-core/src/main/java/org/spockframework/compiler/SpecRewriter.java

spock-core/src/main/java/org/spockframework/runtime/model/ErrorInfo.java

Vampire · 2024-03-21T21:59:35Z

spock-core/src/main/java/org/spockframework/runtime/model/FeatureInfo.java

@@ -42,6 +43,8 @@ public class FeatureInfo extends SpecElementInfo<SpecInfo, AnnotatedElement> imp
  private final List<IMethodInterceptor> initializerInterceptors = new ArrayList<>();
  private final Map<MethodInfo, List<IMethodInterceptor>> scopedMethodInterceptors = new HashMap<>();

+  private final List<IBlockListener> blockListeners = new ArrayList<>();


Should we only have them on FeatureInfo, or also on other levels like IterationInfo and SpecificationInfo or maybe even some global spot?

I think having them just here is enough. Having them on SpecificationInfo is convenience over calling allFeatures*.addBlockListener, or do you think we'd save a significant amount of memory by moving them up.

As for on IterationInfo I fail to see a use-case where you'd only be interested in one iteration for reporting. As noted in the JavaDoc performing side effects is discuraged, so I don't see that as an argument in support.

spock-core/src/main/java/org/spockframework/runtime/model/IErrorContext.java

Vampire · 2024-03-21T22:06:11Z

Btw. could we also support where (and upcoming filter) blocks in a sensible way?

leonard84 · 2024-03-22T00:46:42Z

Btw. could we also support where (and upcoming filter) blocks in a sensible way?

I don't think it would be intuitive or really helpful.
They run outside the normal iteration.
When would you enter or leave the block?

only once when creating the data provider
on every data iterator's iteration?

However, you are most familiar with that part of the code.

Vampire · 2024-03-22T03:57:47Z

When would you enter or leave the block?

No idea. :-D
I guess multiple times.
Maybe with an additional phase enum.
One for creating the data iterators.
One for getting the next set of data variable values.

But we can also start without and see where and how need arises.
But then it needs time to land in production version with our release cadence. :-D

leonard84 · 2024-04-19T16:13:06Z

Forgot to publish my responses 😅

spock-core/src/main/java/org/spockframework/compiler/SpecRewriter.java

spock-core/src/main/java/org/spockframework/runtime/ErrorContext.java

spock-core/src/main/java/org/spockframework/runtime/SpecificationContext.java

spock-core/src/main/java/org/spockframework/lang/ISpecificationContext.java

leonard84 · 2024-04-22T17:50:04Z

Btw, I wonder, if it is still a recommended way to decide if the block listener was intended for the current iteration?

@szpak, can you motivate this use case more? At first glance, I'd try to register a block listener that can handle all iterations instead of one per iteration.

szpak · 2024-04-25T20:00:09Z

@szpak, can you motivate this use case more? At first glance, I'd try to register a block listener that can handle all iterations instead of one per iteration.

Hmm, I think the main problem was to get the invocation instance to obtain the current field instance. As a result, I put IBlockListener inside AbstractMethodInterceptor which provides invocation. Would you propose @leonard84 to pass the invocation instance to the listener in any simpler way?

leonard84 · 2024-05-14T18:19:25Z

@szpak, can you motivate this use case more? At first glance, I'd try to register a block listener that can handle all iterations instead of one per iteration.

Hmm, I think the main problem was to get the invocation instance to obtain the current field instance. As a result, I put IBlockListener inside AbstractMethodInterceptor which provides invocation. Would you propose @leonard84 to pass the invocation instance to the listener in any simpler way?

We could easily pass in the current instance. The question is whether we should.

I've also been debating whether I should give access to the current ISpockExecution so that a listener can get an IStore.

szpak · 2024-05-18T18:19:42Z

Hmm, I think the main problem was to get the invocation instance to obtain the current field instance. As a result, I put IBlockListener inside AbstractMethodInterceptor which provides invocation. Would you propose @leonard84 to pass the invocation instance to the listener in any simpler way?

We could easily pass in the current instance. The question is whether we should.

Definitely that's the good question. What are the design difference between interceptors (which have access to invocation) and listeners (also in work there are intended for)? The first could abort the processing, while listeners should not. Listeners should only perform (external) side effects? What also is different and if invocation in the second case could "complicate" something?

I've also been debating whether I should give access to the current ISpockExecution so that a listener can get an IStore.

Do you see any good cases where it would be necessary for listeners in practice? To read the values set by the other extensions/interceptors?

This feature allows extension authors to register a IBlockListener for a feature to observe the execution of a feature in more detail. This surfaces some of Spock's idiosyncrasies, for example interaction assertions are actually setup right before entering the preceding `when`-block as well as being evaluated on leaving the `when`-block before actually entering the `then`-block. The only valid block description is a constant String, although some users mistakenly try to use a dynamic GString. Using anything other than a String, will be treated as a separate statement and thus ignored.

Prior to this commit, IRunListener.error(ErrorInfo) didn't give any context where the error happened.

leonard84 · 2024-05-22T10:13:37Z

Hmm, I think the main problem was to get the invocation instance to obtain the current field instance. As a result, I put IBlockListener inside AbstractMethodInterceptor which provides invocation. Would you propose @leonard84 to pass the invocation instance to the listener in any simpler way?

We could easily pass in the current instance. The question is whether we should.

Definitely that's the good question. What are the design difference between interceptors (which have access to invocation) and listeners (also in work there are intended for)? The first could abort the processing, while listeners should not. Listeners should only perform (external) side effects? What also is different and if invocation in the second case could "complicate" something?

IBlockListerner is a sibling of IRunListener; both are intended for reporting purposes and not to perform test-relevant side effects.

What you are trying to do (interact with the entity manager) is not in line with the original intention, and I'm still not 100% convinced that it is a good thing. Yet, it would make sense to explore what it would take to support this properly to make an informed decision.

I've also been debating whether I should give access to the current ISpockExecution so that a listener can get an IStore.

Do you see any good cases where it would be necessary for listeners in practice? To read the values set by the other extensions/interceptors?

It would make it possible to access information added by a cooperating extension for that purpose.

szpak · 2024-05-22T18:58:08Z

What you are trying to do (interact with the entity manager) is not in line with the original intention, and I'm still not 100% convinced that it is a good thing.

In that case, maybe it is good to don't have an official support for that 🤷. Probably we don't also want to have a dedicated interceptor for blocks (I'm not sure for what other cases it could be used). In that case the "hack" I used - assuming it is stable - is sufficient for me (and deters potential followers ;-) ). It's the only possibility right now to implement the "flushing extension".

leonard84 · 2024-05-23T18:34:51Z

@szpak FWIW, you can probably get away with using a single instance of each and a ThreadLocal to share the data from the interceptor to the listener.

leonard84 · 2024-05-27T20:19:55Z

@renatoathaydes do you have any comments about the new listeners?

leonard84 · 2024-05-31T10:38:40Z

@Vampire, @szpak, @AndreasTu:

Historically, Spock ignored block labels that were GString expressions, e.g., when: "user ${user.name}" instead, those were kept as standalone GStrings doing mostly nothing, except for expect/then blocks where they would be asserted.
This was mainly because the blocks are stored in @BlockMetadata, which only allows constant strings.

Now we have to decide if we want IBlockListener to support GString expressions as labels. It would be a potential breaking change, although the impact should be negligible. The @BlockMetadata would store the verbatim representation, and the blockEntered/blockExited methods would evaluate the GString when constructing the BlockInfo.

    int idx = 0
    given: "given ${idx++}"
    expect: "expect ${idx++}"
    when: "when ${idx++}"
    then: "then ${idx++}"

would end up with idx == 8 as each enter/exit would increment it.

The alternative would be to stay with only constant strings and with the possible optimization to re-use the existing BlockInfo from he FeatureInfo and access it via index, avoiding the construction of new instances for each block* call.

szpak · 2024-05-31T16:07:40Z

@szpak FWIW, you can probably get away with using a single instance of each and a ThreadLocal to share the data from the interceptor to the listener.

Trying to use ThreadLocal was failing with strange effect at first and in the end, it turned out that my original problem with "wrong iteration" was caused by the fact, I was not removing the block listener added in the iteration interceptor. As a result, in the second iteration 2 listeners were called (and checking the iteration index worked as a workaround)...

In the end, I can use just one block listener without any iteration index checking. Thanks.

https://github.com/szpak/spock-jpa-flush-enforcer/compare/preview2...preview3?expand=1

leonard84 · 2024-05-31T16:16:09Z

@szpak you should just register the blocklister once for the feature where you add the interationInterceptor instead of adding/removing it every time. Otherwise, you'll run into problems in parallel execution mode.

szpak · 2024-05-31T18:34:40Z

@szpak you should just register the blocklister once for the feature where you add the interationInterceptor instead of adding/removing it every time. Otherwise, you'll run into problems in parallel execution mode.

Thanks, fixed:
szpak/spock-jpa-flush-enforcer@54d00a3

szpak · 2024-06-03T20:17:57Z

Regarding GString in labels, I do not have a strong opinion. It might be useful for (more) fancy reporting, so some people might be delighted. On the other hand, I don't know how my (performance) impact it will have.

It would be a potential breaking change, although the impact should be negligible.

Some people might use it as a informal (and broken) placeholders. However, it should be easy to fix.

Btw, could we reuse BlockInfo if no GString is detected, and create a new instance only if an evaluation is needed?

leonard84 · 2024-06-05T21:38:31Z

Btw, could we reuse BlockInfo if no GString is detected, and create a new instance only if an evaluation is needed?

Maybe, with increased complexity.

AndreasTu · 2024-06-06T15:53:52Z

I have no real preference in any way for or against the GString support.

How about we go with the existing behavior, and if someone wants the GString support in the future, we can still make the break?

leonard84 mentioned this pull request Feb 16, 2023

Adding block listener support #111

Closed

szpak reviewed Feb 16, 2023

View reviewed changes

leonard84 force-pushed the add-block-listener-support branch from e49b0e3 to f1d1840 Compare March 10, 2023 10:46

leonard84 commented Mar 10, 2023

View reviewed changes

szpak reviewed Mar 13, 2023

View reviewed changes

leonard84 force-pushed the add-block-listener-support branch from c3f30eb to 0f3197e Compare May 7, 2023 05:41

leonard84 force-pushed the add-block-listener-support branch from 0f3197e to ae38bda Compare February 25, 2024 16:53

leonard84 force-pushed the add-block-listener-support branch from ae38bda to 353cbf9 Compare March 21, 2024 17:20

leonard84 requested review from Vampire and AndreasTu March 21, 2024 17:24

AndreasTu requested changes Mar 21, 2024

View reviewed changes

szpak reviewed Mar 21, 2024

View reviewed changes

Vampire requested changes Mar 21, 2024

View reviewed changes

Vampire requested changes Apr 20, 2024

View reviewed changes

leonard84 force-pushed the add-block-listener-support branch from 5a2f3f2 to c9ee05f Compare April 28, 2024 11:35

leonard84 added 12 commits May 22, 2024 12:04

Expose IErrorContext in ErrorInfo...

a8f4afd

Prior to this commit, IRunListener.error(ErrorInfo) didn't give any context where the error happened.

Clear current block on exit from feature method

1509cbb

Update AST tests with block listeners

7703b1f

Add blockExited to IBlockListener

7782902

Add interaction example AstSpec

55a860d

Fix block listeners for interactions

f6571e9

Implement Review Feedback

062e48c

Fix test in RunListenerSpec

550bdb0

Implement Review comments

f8afc1d

Move current block clearing to PlatformSpecRunner

be53f6d

Move DataProviders expected ast to snapshots

ee91f63

Restore failed block when cleanup runs

d9b7e2e

leonard84 force-pushed the add-block-listener-support branch from c9ee05f to d9b7e2e Compare May 22, 2024 14:17

leonard84 added 2 commits May 23, 2024 20:40

Implement Review comments re SpecificationContext

75cb5e9

Implement Review comments re ErrorContext/Info

ab6311a

leonard84 added 2 commits May 31, 2024 10:58

Revert all changes to DeepBlockRewriter

a01d427

Implement Review Comments

b16eac0

Add BlockListener support... #1575

Are you sure you want to change the base?

Add BlockListener support... #1575

Conversation

leonard84 commented Feb 16, 2023

codecov bot commented Feb 16, 2023 • edited

Codecov Report

szpak Feb 16, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leonard84 Mar 15, 2023 • edited

Choose a reason for hiding this comment

kriegaex Mar 15, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

szpak Mar 15, 2023 • edited

Choose a reason for hiding this comment

kriegaex commented Feb 17, 2023

leonard84 commented Mar 10, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

szpak commented Oct 2, 2023 • edited

leonard84 commented Oct 6, 2023

leonard84 commented Mar 21, 2024

Choose a reason for hiding this comment

leonard84 commented Mar 21, 2024

szpak left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Vampire left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Vampire commented Mar 21, 2024

leonard84 commented Mar 22, 2024

Vampire commented Mar 22, 2024

leonard84 commented Apr 19, 2024

leonard84 commented Apr 22, 2024

szpak commented Apr 25, 2024 • edited

leonard84 commented May 14, 2024

szpak commented May 18, 2024 • edited

leonard84 commented May 22, 2024

szpak commented May 22, 2024

leonard84 commented May 23, 2024

leonard84 commented May 27, 2024

leonard84 commented May 31, 2024

szpak commented May 31, 2024 • edited

leonard84 commented May 31, 2024

szpak commented May 31, 2024

szpak commented Jun 3, 2024

leonard84 commented Jun 5, 2024

AndreasTu commented Jun 6, 2024

codecov bot commented Feb 16, 2023 •

edited

szpak Feb 16, 2023 •

edited

leonard84 Mar 15, 2023 •

edited

kriegaex Mar 15, 2023 •

edited

szpak Mar 15, 2023 •

edited

szpak commented Oct 2, 2023 •

edited

szpak left a comment •

edited

szpak commented Apr 25, 2024 •

edited

szpak commented May 18, 2024 •

edited

szpak commented May 31, 2024 •

edited