This will solve the ticket Record whole scenarios with Cucumber #12

in addition to

• html
• console
• json
• i added a plugin that will generate also html based on the json file, to the verification becomes more easy (https://github.com/damianszczepanik/cucumber-reporting)

Enhance the test suite to verify that variables in tests containing var keywords are correctly recorded. Similar tests can be found in the junit4-tests project. For more info about Local Variable Type Inference, see JEP 286 and JEP 323.

Also, add a failing test to the showcase project, to make sure that the rendered failure message looks pretty.

Note: please make sure to visit the contribution and development guide for some important notes on how to build and debug Scott.

When a loop body is executed multiple times, Scott records and prints variable states from every turn:

  47|      @Test
  48|      public void test() throws Exception {
  49|          int i = 0;  // i=0
  50|          while (i < 10) {
  51|              i = i + 1;  // i=1
    |                          // i=2
    |                          // i=3
    |                          // i=4
    |                          // i=5
    |                          // i=6
    |                          // i=7
    |                          // i=8
    |                          // i=9
    |                          // i=10
  52|          }
  53|*         fail();  // AssertionError
  54|      }

This looks really boring, and should be enhanced.

Maybe print the first and the last few only with the number of the corresponding turn; or simply show the last recorded value?

Currently, Mockito fails while stubbing as scott tries to call toString while mockito is capturing method calls. This could be partially resolved with a check in hu.advancedweb.scott.runtime.track.StateRegistry#objectToString:

	//...
	} else if (MockUtil.isMock(value)) {
		// While setting up mocks with when(...), invoking any method on the mock will
		// cause it to be recorded thus breaking the when() statement.
		return constructMockitoMockObjectString(value);
	}else if (MockUtil.isSpy(value)){
		return "Mockito Spy:" + MockUtil.getMockName(value);
	}	//...

	public static String constructMockitoMockObjectString(Object value){
		return "Mockito Mock("+ MockUtil.getMockSettings(value).getTypeToMock()+")";
	}

Along with the required dependency:

    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-core</artifactId>
        <version>2.2.28</version>
    </dependency>

But it still doesn't solve the case where method calls are inlined when stubbing.

While test driving scott, I've encountered a rather strange exception. If I use Stream.anyMatch, for example:

new ArrayList<String>().stream().anyMatch(s -> false);

A NoClassDefFoundError is thrown for some reason. I've checked scott's source but can't really find anything as I'm not familiar with java instrumentation. Perhaps you can give me some pointers as I'm really impressed with scott and would like to contribute.

The stacktrace:

java.lang.Error:
   0|* ???  // NoClassDefFoundError: hu/advancedweb/scott/runtime/track/StateRegistry
   // removed , my source 
        at hu.advancedweb.scott.runtime.ScottReportingRule$1.evaluate(ScottReportingRule.java:30)
        at org.junit.rules.RunRules.evaluate(RunRules.java:20)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.junit.runners.Suite.runChild(Suite.java:128)
        at org.junit.runners.Suite.runChild(Suite.java:27)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
        at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
        at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.NoClassDefFoundError: hu/advancedweb/scott/runtime/track/StateRegistry
        at java.util.stream.MatchOps.lambda$makeRef$0(MatchOps.java:97)
        at java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230)
        at java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196)
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.util.stream.ReferencePipeline.anyMatch(ReferencePipeline.java:449)
       
	     // stuff that makes call to anyMatch...
	   
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at hu.advancedweb.scott.runtime.ScottReportingRule$1.evaluate(ScottReportingRule.java:26)
        ... 31 more

Hey Dávid!

I was wondering if you have plans for integrating the project into a continuous integration system, like Travis CI. Based on the contribution guide, I guess you can include steps like:

• building and testing the core Scott module (mvn clean install). I believe a setup in Travis CI would be very easy to implement: https://docs.travis-ci.com/user/languages/java/
• maybe you can even build and test the Gradle plugin? I'm not yet sure on the project setup. :/
• add a static analysis solution, e.g. Sonar or Codacy. I have little experience with Codacy, but integration for open source repos is pretty easy to do. Probably worth a try.

Values I see in this change:

• first and foremost valuable feedback for you after commits, even if you are the only developers.
• helps the contribution flow. If you agree with the toolings, automating static analysis should help speed up the reviews.
• the green badge on the README representing the successful build always looks nice. :)

Let me know what you think! Cheers, Balázs

Enhance the test suite to verify that variables in tests containing try-with-resource statements are correctly recorded. Similar tests can be found in the junit4-tests project.

Also, add a failing test to the showcase project, to make sure that the rendered failure message looks pretty.

Note: please make sure to visit the contribution and development guide for some important notes on how to build and debug Scott.

Issue #57 fixed a weird issue with first label vs first instruction order, that affects some environments.

It seems that the fix was only implemented in the ScopeExtractorMethodVisitor, but it also affects the StateTrackingMethodVisitor.

In this case the symtom is not a runtime error while instrumenting, but it causes an invalid trace call to be injected which results in invalid bytecode.

Issue #44

Please read https://guides.gradle.org/publishing-plugins-to-gradle- plugin-portal /

After configuring your credentials you can publish the plugin locale at scott-gradle-plugin folder

$ ./gradlew tasks

Plugin Portal tasks
-------------------
login - Update the gradle.properties files so this machine can publish to the Gradle Plugin portal.
**publishPlugins - Publishes this plugin to the Gradle Plugin portal.**

$ ./gradlew publishPlugins

> Task :publishPlugins
Publishing plugin hu.advanceweb.scott-plugin version 3.3.3
Publishing artifact build/libs/gradle-3.3.3.jar
Publishing artifact build/libs/gradle-3.3.3-sources.jar
Publishing artifact build/libs/gradle-3.3.3-javadoc.jar
Publishing artifact build/libs/gradle-3.3.3-groovydoc.jar
Publishing artifact build/publish-generated-resources/pom.xml
Activating plugin hu.advanceweb.scott-plugin version 3.3.3

To test/approve the PR, I believe you can follow those flow to generate the artifacts and test the changes.

The Junit4 and Junit5 test reports keep detailed information, but only cucumber reports generated by scott.

:brazil:

@Test
public void test_3() {
    String empty = "";
    String first = "1";
    String last = "2";
    String concatenated = empty + first + last;
    assertEquals(12, concatenated);
}

will lead to

java.lang.AssertionError: 
  29|      @Test
  30|      public void test_3() {
  31|          String empty = "";  // empty=
  32|          String first = "1";  // first=1
  33|          String last = "2";  // last=2
  34|          String concatenated = empty + first + last;  // concatenated=12
  35|*         assertEquals(12, concatenated);  // AssertionError: expected: java.lang.Integer<12> but was: java.lang.String<12>
  36|      }
 <Click to see difference>

after click "Click to see difference" link at Intellij, the diff will be reported as

as you can see, there is also the " 36| }" shown as difference

For a failing step in the Cucumber Example, only the failing step definition gets printed. It would be nice if the previous steps would be rendered as well for the failing scenario.

Regular maintenance requires many manual steps:

• Bump asm and javaparser dependencies to ensure that Scott can work with the latest Java.
• Bump ASM constant in the visitors. (E.g. ASM7->ASM8)
• Modify JUnit5 tests and build pipelines to run with latest Java
• Add new tests for some new Java features
• Run all test suites
• Release a new version (doc), including:
  • Bump versions
  • Release artifacts to Maven Central
    • Upload artifacts
    • Manually approve staged artifacts on the Nexus UI
  • Release Gradle Plugin
  • Update version references in the documentation

Ideally, parts of this process should be handled by build pipelines.