Symflower Changelog

This file lists updates to the local version of Symflower and its extensions.

Note that versions of Symflower are automatically created using the current build ID and have no special meaning. As soon as they are ready, all changes are immediately released to all users. Keep in mind that this file is updated weekly, so it may be temporarily out of date with the latest Symflower version.

Changes not marked otherwise apply to all operating systems and components such as editors.

v33073 (2023-11-29)

• NEW Go linter rule: Default clauses should always be the last clause.

  What has changed?

  • Mark default clauses in select and switch statements when they are not the last clause.

  What is the user value, why is this change beneficial?

  • This linter rule forces a consistent position of default clauses, which is also their logical execution order.

v33049 (2023-11-29)

• EPIC Introduce "create test" code lens in VS Code to more easily generate smart test templates for a function or method.

  What has changed?

  • Add "create test" code lens in VS Code for all functions and methods that allow test template generation.

  What is the user value, why is this change beneficial?

  • Every user likes to use different capabilities of editors, e.g. context menu, main menu entries, shortcuts or actions. This change introduces a new capability: a "create test" code lens, which visually tells the user when a function or method can receive tests. Clicking on that code lens generates a smart test template. This feature is currently disabled by default and can be enabled via VS Code's settings, or by setting symflower.editor.codeLens.createTest to true in your VS code settings file. Please send your feedback to hello@symflower.com about this feature, and especially if you find a bug!

v32991 (2023-11-27)

• NEW Introduce Java Spring examples for smart test templates on https://docs.symflower.com/docs/test-templates/spring-boot-test-template-examples/.

  What has changed?

  • Extend the documentation with Symflower's Java Spring support by featuring key component support in smart test templates.

  What is the user value, why is this change beneficial?

  • Java's Spring framework is notoriously complicated. Documenting each Java Spring feature supported by Symflower's smart test template generation should allow a good overview for users, especially users that are new to testing with Java Spring in general.

v32985 (2023-11-27)

• FIXED Always wait for the background tasks of Symflower to finish when exiting.

  What has changed?

  • When exiting Symflower, wait for background tasks to finish their work but do not trigger new work.

  What is the user value, why is this change beneficial?

  • Before this change, it was possible that some information or cache was not yet written or fully written because background tasks had been killed immediately when Symflower wanted to exit. With this change, Symflower always waits for background tasks to finish their work before exiting, leading to correctly written files all the time.

v32970 (2023-11-24)

• NEW Initialize java.util.List with an ArrayList instead of null if no further information is known.

  What has changed?

  • Generate java.util.List with an ArrayList instead of just null.

  What is the user value, why is this change beneficial?

  • Before this change, java.util.List variables e.g. parameters for a method to test were always initialized with null when no further information was defined. Now, an ArrayList is always initialized, giving the user a valid object to work with for test templates.

v32904 (2023-11-22)

• FIXED Allow to generate whole tests and test templates for Java enum methods.

  What has changed?

  • Forward the location of enum methods so they can be addressed in editors.

  What is the user value, why is this change beneficial?

  • Before this change, enum methods did not receive tests nor test templates when they were generated directly "by function" in editors. However, they were always generated when generating for the whole file. With this change, the bug got fixed to forward the missing location information of enum methods so they can now be always addressed.

v32875 (2023-11-22)

• NEW Report as a warning when the used Java version does not match the Java version of the configuration.

  What has changed?

  • Report as a warning when the used Java version does not match the Java version of the configuration.

  What is the user value, why is this change beneficial?

  • Users of Symflower often have a more recent Java version installed than is actually configured for a project e.g. through their build system files. This can lead to problems. Symflower tries to work around these problems and fails when such problems cannot be healed. It is also worth noting to the user when such a scenario occurs as it could be a configuration bug.

v32853 (2023-11-21)

• NEW Report errors of Java unit test execution to the user.

  What has changed?

  • Parse and forward errors of Java unit test executions.

  What is the user value, why is this change beneficial?

  • Previously, Symflower only reported passing or failing tests as well as initialization problems. From now on, the tool also reports errors such as unexpected exceptions.

v32747 (2023-11-17)

• CHANGED Update https://docs.symflower.com/docs/introduction/ with the latest behavior of Symflower.

  What has changed?

  • Update https://docs.symflower.com/docs/introduction/ with the latest behavior of Symflower.

  What is the user value, why is this change beneficial?

  • Symflower's documentation and the examples therein should always be in sync with the latest Symflower version.

v32725 (2023-11-17)

• NEW Cache workspace objects in editors' language server.

  What has changed?

  • Create workspace objects in editors' language server and use them in every action.

  What is the user value, why is this change beneficial?

  • This change allows the caching of Symflower's workspace objects which drastically reduces the execution time for bigger projects. Configurations are now mostly loaded only once. The next step in this area is to introduce more cache for even more configurations and settings of files in a project.

v32721 (2023-11-17)

• NEW Support all officially defined repository types of Java Spring repositories.

  What has changed?

  • Complete list of Java Spring repository types.

  What is the user value, why is this change beneficial?

  • With this change, Symflower now supports testing for all officially supported Java Spring repository types.

v32641 (2023-11-14)

• FIXED Mock Java Spring dependencies annotated with @Component in tests.

  What has changed?

  • Mark Spring org/springframework/stereotype/Component to be auto-wired in tests.

  What is the user value, why is this change beneficial?

  • This change fixes the problem that dependencies marked with the @Component annotation were not auto-wired in tests. This led to generated tests that failed with a fatal configuration error. With this change such dependencies are correctly added to tests via auto-wiring.

v32639 (2023-11-14)

• CHANGED Send environment telemetry every hour to identify old installations.

  What has changed?

  • Send environment telemetry every hour.

  What is the user value, why is this change beneficial?

  • Symflower collects anonymized telemetry about environments for Symflower itself and sends it to our own servers. No third-party vendor ever receives data from us, and no source code is ever sent to our servers or any other servers. These environment reports allow us to investigate if users are staying on old versions that need updating information to fix problems.

v32628 (2023-11-14)

• EPIC Support Java Spring repository components that are declared as an interface.

  What has changed?

  • Generate smart test templates for Java Spring repository components declared as an interface.

  What is the user value, why is this change beneficial?

  • With this change, Symflower now generates test templates for Java Spring repository components declared as an interface. This is the most common form of how repositories, especially JPA-based repositories, are defined.

• NEW Notify the user that abstract functions and methods cannot have a unit test when trying to generate a test suite or test template on them.

  What has changed?

  • Forward error as notifications in case an action is applied to an abstract function or method that is not part of a Java Spring repository interface.

  What is the user value, why is this change beneficial?

  • This change adds an error notification that lets the user know when a test cannot be generated for an abstract function or method.

• FIXED Mark all of a user's source code problems with "error" severity instead of "internal" severity to convey that it is not a Symflower issue.

  What has changed?

  • Always forward the severity of source code problems.

  What is the user value, why is this change beneficial?

  • Symflower tries to automatically repair problems for the user where possible. However, in the case of source code errors, e.g. syntax errors, Symflower needs to ask the user to repair the problem. This change now forwards all user errors of the source code with the correct severity "error" to make it clear that the problem needs to be fixed by the user.

v32615 (2023-11-14)

• CHANGED Upgraded to Go 1.21

  What has changed?

  • Symflower is now compiled with Go 1.21.4 instead of 1.20.6.

  What is the user value, why is this change beneficial?

  • Fixed multiple CVEs.
  • This yields up to 10% faster execution on all actions by Symflower.

v32598 (2023-11-13)

• FIXED Allow the current path pattern "." in all file path filters of Symflower CLI.

  What has changed?

  • Clean file paths completely, no matter the OS, to allow the "." pattern in all file paths.

  What is the user value, why is this change beneficial?

  • Before this change, the current path pattern "." was marked as an invalid path. Thanks to all your bug reports, it is clear that our users like to use "." for filtering. For example, **.java which filters for all Java files in the current directory recursively can be written as ./**.java (or .\**.java for Windows users). With this change, all "." mentions for a directory are correctly applied.

v32532 (2023-11-10)

• NEW Give a bigger introduction on smart test templates at https://docs.symflower.com/docs/test-templates/test-template-examples/

  What has changed?

  • Start of an in-depth documentation for smart test templates at docs.symflower.com.

  What is the user value, why is this change beneficial?

  • Documenting all features and nuances of Symflower gives users who like to read, or companies who require documentation, the chance to see if Symflower already implements their requirements. With this change we are starting to document every single feature of Symflower's smart test templates with in-depth examples that you can try yourself.

v32498 (2023-11-09)

• NEW Allow to install Java if necessary on Linux, MacOS, and Windows via Symflower.

  What has changed?

  • Integrate installing Java into Symflower.

  What is the user value, why is this change beneficial?

  • Symflower will in the future allow to migrate to newer versions of Java as well as test in the background existing test cases instead of the foreground. With this change we take the first step of allowing to install Java with Symflower itself. From a user point of view, we only install versions that the user can actually use for free. Hence, no licenses are needed.

v32455 (2023-11-08)

• EPIC Support Mockito for Spring (Boot) testing.

  What has changed?

  • Generate test templates with Mockito if Mockito was used before.

  What is the user value, why is this change beneficial?

  • This change detects when Mockito is used for testing and generates tests using Mockito on using Symflower smart test templates.

• FIXED Use the type to call static methods in Java for testing static methods of Spring components.

  What has changed?

  • Use the type instead of the mocking object to call static methods in Java when testing them.

  What is the user value, why is this change beneficial?

  • Before this change, Symflower would access static methods of Java Spring components, e.g. controllers, via their mocked types (that is usually auto-wired in tests). Even though this does lead to no execution problems, it is still not the common convention in Java. With this change, the common convention of using the type for calling static methods is used.

• CHANGED Generate a default test template in case a non-native Java Spring parameter for @ExtendWith annotation was found instead of an integration test.

  What has changed?

  • Generate a regular test template if an unknown parameter for @ExtendWith was found.

  What is the user value, why is this change beneficial?

  • Using @ExtendWith allows different ways of testing in Java Spring. With this change, Symflower now generates regular unit tests instead of integration tests if unknown parameters for @ExtendWith have been found. Most commonly @ExtendWith(MockitoExtension.class) which is used to do mocking over Mockito instead of Java Spring's mocking.

v32441 (2023-11-08)

• FIXED Forward execution coverage for empty-body functions and methods when executing Java tests.

  What has changed?

  • Always mark empty-body functions and methods as covered when they are executed without compilation and execution errors, and ignore the native coverage tool if it does not find coverage.

  What is the user value, why is this change beneficial?

  • Some native Java coverage tools report no coverage for functions and methods with an empty body, i.e. {}. However, reporting no coverage is an error for Symflower as it does not fit with the predicted execution path. With this change, all such executions regardless of the native coverage tool are correctly marked as executed when there are no compilation or execution errors besides the "no coverage" error of the tool.

v32399 (2023-11-07)

• NEW Go linter rule: Always use backticks "`" as quotation for attributes.

  What has changed?

  • Mark attribute quotes that are not using backticks: "`".

  What is the user value, why is this change beneficial?

  • This rule forces attribute quotes to consistently use backticks "`" as their quotation.

v32397 (2023-11-07)

• NEW Go linter rule: Use errors.New instead of fmt.Errorf when no arguments besides the error message are given.

  What has changed?

  • Mark fmt.Errorf(x) to be replaced by errors.New(x).

  What is the user value, why is this change beneficial?

  • Using functions with formatting usually comes with an overhead. By avoiding such functions and using non-formatted versions instead, code is not only consistent but also takes less resources when executed..

v32369 (2023-11-06)

• NEW Go linter rule: Check that a slice/map is nil before checking its length.

  What has changed?

  • Mark expressions like len(x) == 0 && x != nil that first check the length of an expression before checking if an expression is nil.

  What is the user value, why is this change beneficial?

  • This rule marks inconsistencies in checking slices and maps for nil and their length. Usually, it is not necessary to check if a list is nil or not as the length check is sufficient. However, if an algorithm requires a check for nil to have an allocated but empty list, this rule will make them consistent.

v32338 (2023-11-03)

• CHANGED Forward Maven configuration problems as soft errors instead of failing immediately.

  What has changed?

  • Forward Maven configuration problems as soft errors.

  What is the user value, why is this change beneficial?

  • Before this change, all Maven configuration errors led to Symflower failing immediately. However, most of the time Symflower can heal the configuration using default values e.g. the Java version can be inferred in other ways. This allows Symflower to function, analyze, and generate tests without the user being disturbed.

v32332 (2023-11-03)

• FIXED Fully resolve recursive variables in Maven configurations.

  What has changed?

  • Resolve variables in Maven configurations recursively.
  • Report non-defined variables of Maven configurations.

  What is the user value, why is this change beneficial?

  • Variables in Maven configurations are a useful mechanism to clearly define configurations, e.g. define a variable for the Java version and use it in multiple plugin configurations. However, some Maven configurations of Symflower users redefine variables multiple times within variables. With this change, such configurations are now fully supported.

• NEW Send telemetry for fatal errors of language server requests and notifications.

  What has changed?

  • Send telemetry for fatal errors of language server requests and notifications.

  What is the user value, why is this change beneficial?

  • Symflower collects anonymized error reports for Symflower itself and sends them to our own servers. No third-party vendor ever receives data from us, and no source code is ever sent to our servers or any other servers. These error reports allow us to now identify fatal errors of the language server, the server that editors communicate with. This will allow us to fix problems more easily.

v32328 (2023-11-03)

• NEW All Java version declarations in Maven files are now correctly parsed.

  What has changed?

  • Query and prioritize Java version declarations in Maven files to pick the Java version for the underlying Java source code.

  What is the user value, why is this change beneficial?

  • To parse and generate source code that is compatible with the user's project, Symflower needs to have the correct version of the underlying Java source code. With this change, all commonly defined and reported Java version declarations are successfully parsed and automatically forwarded.

v32305 (2023-11-02)

• CHANGED Completely remove white spaces in log entries for clear and concise messages.

  What has changed?

  • Remove white spaces of log entries.

  What is the user value, why is this change beneficial?

  • Log entries are now free of white spaces which have been partly used for grouping sub-entries together. With this change, such white spaces have been removed and other grouping mechanisms, e.g. referencing of group IDs, are now fully in place.

v32299 (2023-11-01)

• CHANGED Clarify the CLI description for the log path option as it disabled printing the logs.

  What has changed?

  • Add to the CLI's log path option that it also disables the printing of log entries.

  What is the user value, why is this change beneficial?

  • The log path option of the CLI used to only describe that log entries are written to the given file path. With this change, it is made clear that log entries are not printed.

v32234 (2023-10-26)

• FIXED When updating Symflower, always retry downloading the Symflower binary in the case of errors.

  What has changed?

  • Always retry downloading the Symflower binary if it fails.

  What is the user value, why is this change beneficial?

  • Before this change, users would sometimes need to retry updating Symflower. With this change, Symflower automatically retries, leading to less failures at updates. This is especially important for users with bad internet connections or proxies.

v32229 (2023-10-26)

• FIXED Retry Maven commands if a caching/tracking file could not be written because that is usually a temporary failure.

  What has changed?

  • Retry Maven commands if a caching/tracking file could not be written.

  What is the user value, why is this change beneficial?

  • Before this change, every Maven command would fail when a cache/tracking file could not be written for any reason. With this change, Symflower retries on such failures because they are usually temporary. This leads to less failures for users using Maven in their projects.

v32220 (2023-10-26)

• FIXED Always add a new line after Java annotations.

  What has changed?

  • Correctly update the positions of existing Java annotations and AST nodes to have every Java annotation in its own line.

  What is the user value, why is this change beneficial?

  • Before this change, some existing code could lead to Symflower generating Java annotations in the same line as the code (e.g. class declaration) they are annotating. This violates a common Java convention to put every annotation in its own line. With this change, this convention is fully respected.

v32214 (2023-10-26)

• FIXED Allow javax/xml/ws/handler/Handler as a valid Java Spring controller request parameter type.

  What has changed?

  • Mark javax/xml/ws/handler/Handler as a valid Java Spring controller request parameter type.

  What is the user value, why is this change beneficial?

  • With this change, we handle javax/xml/ws/handler/Handler as types in Java Spring controllers.

v32207 (2023-10-25)

• FIXED Generate non-empty test templates for Java Spring controller constructors and methods that do not have a request mapping annotation.

  What has changed?

  • When generating a test template, forward methods of Java Spring controllers without a request mapping annotation to the generic test template generation.

  What is the user value, why is this change beneficial?

  • Before this change, Java Spring controller constructors and methods had an empty test case generated when Symflower's test template functionality was used. With this change, full-blown test templates are generated, which drastically reduces the time to test.

v32195 (2023-10-24)

• CHANGED Forward the output of failing Gradle/Maven commands to allow users to more easily debug problems.

  What has changed?

  • Forward output of failing Gradle/Maven commands to the user.

  What is the user value, why is this change beneficial?

  • Build system commands that use Gradle or Maven can fail for various reasons. Symflower tries to repair problems with known solutions automatically to avoid wasting the user's time with easy-to-resolve problems. However, when a command fails, it is necessary for the user to see the actual output. With this change, we now forward all Gradle and Maven failures to the user.

v32188 (2023-10-24)

• NEW Go linter rule: Use strconv.Atoi instead of strconv.ParseInt when it is simpler.

  What has changed?

  • Mark strconv.ParseInt(..., 10, 0) usages to be replaced by strconv.Atoi.

  What is the user value, why is this change beneficial?

  • This new rule will make code consistent by only using the simplest version to convert a "string" to an "int".

• NEW Go linter rule: Use any instead of interface{} as it's shorter and clearer.

  What has changed?

  • Mark usages of interface{} to be replaced by any.

  What is the user value, why is this change beneficial?

  • Symflower's Go linter is currently not enabled by default. From now on we would like to introduce new features directly to our users and enable the linter by default for all users of Symflower as it is super fast. This new rule will make code consistent by only using any instead of allowing interface{} as well.

v32181 (2023-10-23)

• CHANGED Make marketplace descriptions and READMEs of JetBrains' IDEs and VS Code easier to skim.

  What has changed?

  • Summaries main features and installation at the top of the descriptions and READMEs.
  • Align content to have the same in-depth content over all descriptions and READMEs for non-skimmers.

  What is the user value, why is this change beneficial?

  • During developer interviews and sessions, we noticed that developers like to skim over content, which requires content to be short and precise. However, there are also people who do like to read more detailed content. With this change, both types of users are addressed.

v32148 (2023-10-21)

• FIXED Detect and respect the usage of SpringJUnit4ClassRunner.

  What has changed?

  • Do not rewrite usage of SpringJUnit4ClassRunner.

  What is the user value, why is this change beneficial?

  • Spring defines the commonly used SpringRunner as an alias for SpringJUnit4ClassRunner for testing with JUnit 4. Symflower now fully detects and respects the usage of SpringJUnit4ClassRunner, i.e. tests are generated for the correct JUnit version and tests are not rewritten.

• NEW Generate generic test template when Symflower does not understand a test context given with @RunWith.

  What has changed?

  • Instead of an empty template, generate a generic test template when Symflower does not understand the test context given with @RunWith.

  What is the user value, why is this change beneficial?

  • Using the @RunWith annotation allows users to apply custom test contexts that Symflower might not yet understand. In such cases, Symflower now generates a generic test template instead of an empty template to make users more productive in writing and maintaining tests.

• FIXED Never add a @RunWith annotation if a @RunWith annotation already exists.

  What has changed?

  • Never add a @RunWith annotation if a @RunWith annotation already exists.

  What is the user value, why is this change beneficial?

  • With this change, Symflower never adds a second @RunWith annotation, fully respecting the user's decisions for the test context. A fix for this bug was requested by a lot of our users and we are eager to hear your feedback at hello@symflower.com on how well Spring and Spring Boot testing now work for you.

• FIXED Add the Spring @RunWith annotation for JUnit 4 testing when a test annotation already exists.

  What has changed?

  • Add the Spring @RunWith annotation for JUnit 4 testing when a test annotation already exists.

  What is the user value, why is this change beneficial?

  • For testing with JUnit 4, the @RunWith annotation with the correct test context is required to be able to execute tests. With this change, Symflower adds the @RunWith annotation when an existing test annotation is found.

v32130 (2023-10-20)

• EPIC Correctly infer if JUnit 4 or JUnit 5 should be used for existing test files in cases where it is not obvious.

  What has changed?

  • Infer the correct JUnit version for all known existing test file scenarios for JUnit 4 and JUnit 5.

  What is the user value, why is this change beneficial?

  • Existing test files sometimes do not have a clear usage of JUnit 4 or JUnit 5. Based on the annotations and imports used, Symflower now detects if JUnit 4 or JUnit 5 tests should be generated. If this does not work for your project, please let us know at hello@symflower.com!

• EPIC Handle all known scenarios for incomplete existing test files for JUnit 4 and JUnit 5 when generating test suites and test templates.

  What has changed?

  • Handle all known existing test file scenarios without a test class for JUnit 4 and JUnit 5.
  • Handle all known existing test file scenarios with a class without annotations for JUnit 4 and JUnit 5.
  • Handle all known existing test file scenarios with a test class without tests for JUnit 4 and JUnit 5.
  • Handle all known existing test file scenarios with and without a test class for Spring and Spring Boot tests with and without annotations for JUnit 4 and JUnit 5.

  What is the user value, why is this change beneficial?

  • Most projects have existing test files that Symflower will add tests to. However, some of these test files are incomplete or broken. Symflower is now able to fully repair and add to such files.

v31997 (2023-10-16)

• CHANGED Update all NPM packages of the Visual Studio Code extension to the newest version.

  What has changed?

  • Update all NPM packages of the Visual Studio Code extension to the latest stable versions.

  What is the user value, why is this change beneficial?

  • Regularly updating dependencies commonly eliminates general bugs, makes the extension faster and lets it use less memory. This is especially noticeable when starting Visual Studio Code or the extension itself.

v31989 (2023-10-15)

• CHANGED Update JavaScript target for Visual Studio Code's TypeScript version to ES2019 (from ES2016).

  What has changed?

  • Update TypeScript target to ES2019.

  What is the user value, why is this change beneficial?

  • Updating the targeted JavaScript version for TypeScript helps apply the newest JavaScript runtime and language features. This reduces CPU and memory usage. Additionally, updating the target aligns with the common Visual Studio Code source code, which reduces the chance of hitting strange bugs.

• CHANGED Give broken internet connections more time to send telemetry before reaching a timeout.

  What has changed?

  • Instead of seconds, we now give a user's internet connection up to a minute to recover and retry sending telemetry.

  What is the user value, why is this change beneficial?

  • Since all Symflower servers are currently located in Europe, lots of users have high delays in sending telemetry. Even though telemetry is sent home asynchronously, it is better to give users' internet connections some more time to adjust. This dramatically improves the data we gather for Symflower and allows the product and development teams to better decide on what to implement and fix next.

v31963 (2023-10-13)

• NEW Symflower now parses all commonly used Java versions from Maven configuration files.

  What has changed?

  • Implemented parsing of Java versions described at https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html.
  • Implemented parsing of Java versions described at https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html.
  • Implemented parsing of Java versions described at https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-starters/spring-boot-starter-parent/build.gradle.

  What is the user value, why is this change beneficial?

  • Before this change, Symflower only parsed common Java version from the binary. With this change, Symflower parses all commonly defined Java versions from Maven configuration files. In the following iterations, Gradle will be aligned as well, and Symflower will be able to select the correct Java binary out of the currently installed Java versions. Additionally, Symflower will be able to automatically install Java if not present.

v31945 (2023-10-12)

• FIXED Do not auto-wire TestEntityManager when it is not needed.

  What has changed?

  • Only auto-wire TestEntityManager when it is needed.

  What is the user value, why is this change beneficial?

  • The TestEntityManager is only usable for JPA testing through a JPA context, i.e. TestEntityManager should be only added for auto-wiring if tests are generated in a JPA context. With this change, Symflower no longer auto-wires TestEntityManager for a Spring or Spring Boot test context.

v31941 (2023-10-12)

• FIXED Use Spring Boot's @SpringBootTest for a Spring Boot test context for the integration testing of services.

  What has changed?

  • Switch from @DataJpaTest to @SpringBootTest for annotating test classes when integration testing Spring Boot services as @DataJpaTest does not auto-wire dependencies.

  What is the user value, why is this change beneficial?

  • Before this change, Symflower relied on @DataJpaTest for generating integration tests for some Spring Boot services. However, @DataJpaTest does not auto-wire dependencies automatically, which results in execution failures due to missing dependencies. With this change, Symflower's test templates use @SpringBootTest to create the Spring Boot test context which comes with a bigger load but is always correct. That means less maintenance and editing work for Symflower users.

v31773 (2023-10-04)

• CHANGED Ensure that Spring @Service services are auto-wired for @Component components with a test case.

  What has changed?

  • Added a test case to ensure that Spring @Service services are auto-wired for @Component components with a test case.

  What is the user value, why is this change beneficial?

  • Usually, we do not mention test cases in our changelog. However, the scenario of having a service auto-wired for a Spring component has not been seen in our collection of repositories. If you have such cases, please let us know at hello@symflower.com. We highly appreciate your help in helping our testing efforts to make sure Symflower works perfectly for everyone!

v31714 (2023-10-02)

• FIXED Do not mark test executions that result in "no coverage" through JVM execution as failures when they are bound to fail or are just empty functions.

  What has changed?

  • Do not mark test executions that result in "no coverage" through JVM execution as failures when they are bound to fail or are just empty functions.

  What is the user value, why is this change beneficial?

  • Marking a "no coverage" test execution as a failure was previously a reason for Symflower's test execution to mark test cases as failures. However, when a test is expected to fail or in previously unsupported empty function scenarios, there is no coverage provided with some coverage tools running in the JVM. These scenarios are now, as expected, marked as valid.

v31682 (2023-09-29)

• CHANGED Make api.symflower.com and downloads.symflower.com more stable.

  What has changed?

  • Rework service handling and routing for api.symflower.com, docs.symflower.com, and downloads.symflower.com to allow a real zero-down deployment for every change, no matter how big.
  • Rework monitoring of api.symflower.com, docs.symflower.com, and downloads.symflower.com to make it possible to react to failures or instability in less than 2 minutes.

  What is the user value, why is this change beneficial?

  • Both api.symflower.com, docs.symflower.com, and downloads.symflower.com are necessary for all Symflower users to not just install and update Symflower, but also to interact for licensing and metrics. Making these services more stable results in a smoother experience for all users, new and old.

v31661 (2023-09-26)

• CHANGED Temporarily update the minimum versions of JetBrains IDEs (IntelliJ, GoLand and Android Studio) to 2022.1.

  What has changed?

  • Update JetBrains IDE minimum versions to 2022.1.

  What is the user value, why is this change beneficial?

  • Because of some newer changes upstream, we temporarily need to update the minimum version of JetBrains IDEs (IntelliJ IDEA, GoLand, and Android Studio) to 2022.1. This ensures that we can still release fixes and features for 2022.1 and later. However, this also means that we have to temporarily drop support for all versions before 2022.1. It is getting harder to support old IDEs for us. Still using an older IDE? Please let us know why you cannot update to a newer release by writing to hello@symflower.com. We are working on a workaround to re-enable support for 2021 versions.

• CHANGED Migrated from "minidev.json" to "org.json" for JSON functionality in JetBrains editors.

  What has changed?

  • Migrated JetBrains extension from "minidev.json" to "org.json".

  What is the user value, why is this change beneficial?

  • JetBrains deprecated and removed "minidev.json" from its IDEs in the latest version 2023.3. Symflower is now using "org.json" which is a widely used and highly stable alternative. Even though "org.json" is slower, we favor stability first.

v31493 (2023-09-15)

• FIXED Concurrent analysis of dependencies could lead to a deadlock.

  What has changed?

  • Always atomically lock when adding an analyzed dependency to the list of dependencies.

  What is the user value, why is this change beneficial?

  • Loading lots of dependencies at the same time when resources are available should now never lead to a deadlock.

• FIXED Do not load packages with empty package paths of non-user-project dependencies since they are not accessible anyhow.

  What has changed?

  • Do not load packages with empty package paths of non-user-project dependencies.

  What is the user value, why is this change beneficial?

  • When loading a dependency, Symflower parses every single file and adds it to the collection of a dependency. Before this change, this included files that hold "main" functions. However, such files usually have no packages and should not be loaded as none of their code is exported. Such files wasted resources that could be better used, and led to many additional reported problems.

v31482 (2023-09-15)

• NEW Extend internal testing with additional Spring and Spring Boot repositories of a mix of diverse Gradle and Maven use.

  What has changed?

  • Extend list of repositories with additional Gradle and Maven scenarios.

  What is the user value, why is this change beneficial?

  • We are constantly extending our broad testing corpus to make sure that we catch problems in the diverse Java ecosystem. If you have an open (or closed) source repository that you can share with us, please email us at hello@symflower.com! With that, you can make sure that Symflower always works for your use cases.

v31444 (2023-09-13)

• EPIC Allow "default values" to have soft errors instead of hard errors only.

  What has changed?

  • Allow "default values" to have soft errors instead of hard errors only.

  What is the user value, why is this change beneficial?

  • Symflower generally uses a set of algorithms in the test template functionality to generate initializations of variables, e.g. parameters. These algorithms generate initializations that are not connected to the real implementation. We call this functionality "default values", and it helps generate test templates that are usable right away for every software developer and tester. This functionality used to only generate "null" as an initialization for Java variables when a problem occurred e.g. when a dependency was not loaded, which led to Symflower not having enough information. With this change, the default value functionality now allows soft errors which enables Symflower to recover problems in a lot of scenarios. A greater number of test templates now have much more initialization code that compiles and matches your source code. This leads to a much more productive time when writing tests with Symflower.

v31408 (2023-09-12)

• NEW Support constant values inside Spring Boot request mapping annotations.

  What has changed?

  • Evaluate constant expressions for Spring Boot request mapping annotations.

  What is the user value, why is this change beneficial?

  • Developers using Spring Boot often rely on using constants for request mapping annotations to not repeat themselves (e.g. instead of repeating what a user ID looks like) and to improve code readability and maintainability. Symflower now correctly evaluates such constant expressions, e.g. @GetMapping("/users/" + USER_ID_REGEX + "/").

v31387 (2023-09-12)

• NEW Validate that only one visibility modifier is used.

  What has changed?

  • Allow at most one visibility modifier per declaration.

  What is the user value, why is this change beneficial?

  • Visibility modifiers (in Java private, protected and public) are mutually exclusive. Previously, Symflower did not do this check, as most often a validating tool like a compiler is used before Symflower. However, Symflower should always catch programming mistakes early to always generate deterministic and perfect results. In cases where there are multiple visibility modifiers, it is not clear what to do. Hence, Symflower should not generate tests for such declarations.

v31379 (2023-09-11)

• CHANGED Update the marketplaces of JetBrains' based IDEs and Visual Studio Code to align with Symflower's current direction.

  What has changed?

  • Update marketplace READMEs and their content to reflect the latest directions in Symflower's development.

  What is the user value, why is this change beneficial?

  • We continue to keep our READMEs up to date to give old and new users a clear view on what Symflower is currently working on. Our current focus is extending Java support to include all language constructs up to Java 21, and supporting bigger and more dependencies, including pure Spring applications and Spring Boot applications using Gradle as well as Maven.

v31373 (2023-09-11)

• CHANGED Improve the quality of screenshots and videos.

  What has changed?

  • Switch from MP4 with x264 as a base of videos and video-screenshots to APNG.

  What is the user value, why is this change beneficial?

  • Some screenshots of Symflower's marketplaces READMEs and documentation are based on videos. Previously, we lost quality especially in screenshots due to lossy encoding. From now on, APNG is used when recording editor and terminal usage for better quality.

v31331 (2023-09-07)

• NEW Use real default values that always compile and execute for Spring Boot request parameters.

  What has changed?

  • Use real default values that always compile and execute for Spring Boot request parameters.

  What is the user value, why is this change beneficial?

  • Given the type information that is available for generating Spring Boot controller integration tests, Symflower now always generates directly usable values for request parameters (and other occurrences of literal values), e.g. instead of .param("someEnum", "<value>") Symflower now generates .param("someEnum", "SOME_ENUM_CONSTANT").

v31254 (2023-09-01)

• EPIC The @ModelAttribute and @Valid annotations are now fully considered for Spring Boot controller integration tests.

  What has changed?

  • Consider the whole chain of @ModelAttribute annotations for types of Spring Boot controller integration tests.
  • Consider the @Valid annotation for Spring Boot controller parameters.

  What is the user value, why is this change beneficial?

  • The @ModelAttribute and @Valid annotations allow developers to define base parameters quickly for a whole class of even a subclass. With this change, we support all common scenarios, which results in correct type information. Hence, test templates now generate better initializations in such cases, making developers and testers much more productive when writing tests with Symflower.

• NEW Do not assert or set a Spring Boot controller request parameter if it has the required attribute set to false.

  What has changed?

  • Do not assert or set a Spring Boot controller request parameter if it has the required attribute set to false.

  What is the user value, why is this change beneficial?

  • Previously, all Spring Boot controller request parameters were added. However, some parameters are optional and it does make sense to reduce the view context to a minimum. We are looking for feedback on this change. Please write to hello@symflower.com if you prefer optional parameters being generated.

• FIXED Use the same order of declaring Spring Boot controller request parameters as in the source code.

  What has changed?

  • Order Spring Boot controller request parameter calls by the order of the user rather than alphabetically.

  What is the user value, why is this change beneficial?

  • Developers have a good reason for ordering their parameters in their source code. With this change, Spring Boot request parameters obey this order instead of sorting them by the alphabet.

• NEW Allow java.lang.Class as a parameter in all Spring Boot functionality.

  What has changed?

  • Include the java.lang.Class type in the Spring Boot generation.

  What is the user value, why is this change beneficial?

  • The type java.lang.Class, which is most often used for reflection, is part of the parameter functionality of Spring Boot. Symflower now includes it (and, hence all officially supported parameter types) for generating test templates.

v31173 (2023-08-30)

• FIXED Do not skip generating assertion calls in unit tests for Spring Boot components so all return values are correctly asserted.

  What has changed?

  • The generation of assertions for return arguments in unit tests had been disabled for Spring Boot components as not every type combination could be resolved. This change now enables all assertions for return arguments, as all common types are now supported.

  What is the user value, why is this change beneficial?

  • Spring Boot components sometimes requires unit tests instead of integration tests. Not all combinations of those unit tests received assertions for return arguments. With this change, all of them now receive assertions as expected.

v31153 (2023-08-29)

• FIXED Correctly handle the abstract modifier for declarations inside of annotation interface declarations.

  What has changed?

  • Allow the abstract modifier for declarations inside of annotation interface declarations.

  What is the user value, why is this change beneficial?

  • The abstract modifier is hardly used inside of annotation interface declarations because it is the default. However, some code does use the modifier and this is now supported by Symflower as expected.

v31114 (2023-08-23)

• NEW Consider @ModelAttribute annotated methods to set the type of Spring Boot controller request parameters.

  What has changed?

  • Consider @ModelAttribute annotated methods to set the type of Spring Boot controller request parameters.

  What is the user value, why is this change beneficial?

  • Previously, the @ModelAttribute annotation was not considered at all. With this change, we took another leap towards perfecting type resolution of Spring Boot integration tests has been done. Spring Boot controller request parameters that have a type with a method that has a @ModelAttribute now inherit this type correctly. As an example, before this change, this.mockMvc.perform(post("/owners/{ownerId}/pets/{petId}/visits/new", "abc", 123) was generated, leading to a wrong "abc" literal for the owner ID. Now, Symflower generates this.mockMvc.perform(post("/owners/{ownerId}/pets/{petId}/visits/new", 123, 123) because the type is resolved through the annotation.

v31100 (2023-08-22)

• CHANGED Rank empty constructors over copy constructors for default value initialization.

  What has changed?

  • Rank empty constructors over copy constructors for default value initialization.

  What is the user value, why is this change beneficial?

  • Previously, copy constructors like SomeType(SomeType), have been chosen before empty constructors like SomeType(), which was OK for most scenarios. However, this update now changes this to consistently choose the empty constructor because users usually do not apply a copy constructor in tests. This change is a productivity improvement for all users using test templates.

• FIXED Make sure that Symflower always chooses the simplest constructor of boxed types (e.g. java.lang.Boolean(bool))

  What has changed?

  • Make sure that Symflower always chooses the simplest constructor of boxed types which references its primitive counterpart. Prior to this, there were instances in nested constructor initializations that Symflower did not choose correctly.

  What is the user value, why is this change beneficial?

  • By choosing the constructor with the primitive counterpart for boxed types, Symflower always correctly converts such initializations to primitive literals, e.g. Boolean(true) is converted to just true, which is both more readable and more maintainable.

• FIXED Avoid running into stack overflows when finding a suitable constructor for a default value in test templates.

  What has changed?

  • Some constructors reference themselves multiple times which led to an infinite loop while finding a suitable constructor. This change lets the analysis wait when a type is already under investigation for a suitable constructor.

  What is the user value, why is this change beneficial?

  • This change makes sure that Symflower does not crash when generating test templates. Many thanks to all the people who reported this. Such problems are very hard to find and we greatly appreciate your reports!

v31096 (2023-08-22)

• CHANGED Set default value for enum types to an enum constant instead of a null value for test templates.

  What has changed?

  • Set default value for enum types to an enum constant instead of a null value for test templates.

  What is the user value, why is this change beneficial?

  • Having an enum constant instead of null in test templates allows users to be more productive in changing tests according to their needs.

v31059 (2023-08-18)

• FIXED Separately cache test suite and test template transpilation objects.

  What has changed?

  • Previously, test suite and test template transpilation objects did overwrite each other. Now, those objects are cached on their own.

  What is the user value, why is this change beneficial?

  • Some objects are shared between all actions of Symflower, some are not. In the case of transpilation objects, a big chunk is not shared between test suite and test template actions and was constantly overwritten. With this change, we correctly separate all transpilation caches.

v31058 (2023-08-18)

• FIXED Correctly parse Java's keywords "yield", "module" and "sealed".

  What has changed?

  • Previously, Java's keywords "yield", "module" and "sealed" led to parsing errors as a bug was introduced in the parser's definition. Now, these keywords are correctly parsed again.

  What is the user value, why is this change beneficial?

  • Even though Symflower does not yet support all new keywords, it simply avoids analyzing unsupported code. With this change files that used the previously unparsable keywords now can be analyzed as expected.

v31034 (2023-08-17)

• CHANGED Treat the standard library dependency of Java like any other dependency.

  What has changed?

  • Previously, the standard library dependency of Java was marked and treated as its own dependency, now it is just another dependency.

  What is the user value, why is this change beneficial?

  • Reducing the complexity of dependency handling reduces the number of hidden bugs. This change in particular also allows to set a specific standard library (JDK) by changing the dependency list of an analysis. This allows a new Java version to use an old JDK.

• FIXED Fail on fatal dependency errors instead of swallowing such errors.

  What has changed?

  • Forward fatal dependency errors.

  What is the user value, why is this change beneficial?

  • Fatal dependency errors e.g. internal problems used to stop the analysis process. However, such errors were not displayed because they were simply dropped. Such errors are now correctly forwarded and displayed to the user.

v30949 (2023-08-10)

• CHANGED Handle unsupported types when constructing constructor calls.

  What has changed?

  • Handle unsupported types when constructing constructor calls by creating empty calls to the unknown type.

  What is the user value, why is this change beneficial?

  • Some type kinds are simply not yet implemented by Symflower. However, in Java, these types are always reference types which usually have an empty constructor. Instead of simply giving up and not generating source code, Symflower now generates an empty constructor call for such unsupported types.

• FIXED Correctly mark scope leak errors as internal errors.

  What has changed?

  • Previously, scope leak errors have been accidentally marked as unsupported errors. Now, they are correctly marked as internal errors.

  What is the user value, why is this change beneficial?

  • Scope leaks are a major bug in how Symflower traverses source code. Making users aware of such problems helps to report them, and in turn helps the Symflower team to quickly fix them to allow users to analyze more source code.

• EPIC Rework how problems are collected during parsing and transpilation to drastically reduce CPU usage and memory footprint.

  What has changed?

  • Use a unique fingerprint to add problems per file only once. Before we added certain problems to a scope level which worked well for a few errors but does not scale when handling hundreds of errors over hundreds of dependencies at once.
  • Certain user errors, e.g. unknown imports, are now reported per file, i.e. the same unknown import can be reported multiple times. Since this should be a rare problem to reach Symflower, we think the benefits of a highly reduced resource usage outweigh the benefit of less problems for now. The end result for us should mirror how compilers e.g. "go" or "javac" report such compilation errors.

  What is the user value, why is this change beneficial?

  • When analyzing source code, Symflower gathers a lot of problem objects to let users better understand why a certain code was not analyzed. Most projects have a huge set of dependencies, e.g. if you import a package of Spring Boot hundreds of packages are usually loaded. Such an amount of code often comes with all kinds of corner cases that have not been implemented by Symflower, leading to a massive amount of problems being gathered. In turn, these problems resulted in additional work being done as well. This change reduces the CPU usage and memory footprint drastically for such scenarios, e.g. in one scenario 50GB of copying of AST objects reduced to 2GB, and peak memory went from 20GB to 8GB. This reduction also reduces the work the GC needs to do to a minimum. The whole scenario before taking minutes now just takes seconds to compute. Overall this change improves CPU and memory usage for all scenarios and makes every action faster.

v30876 (2023-08-07)

• FIXED Allow semicolons after Java global and type level declarations as they are just empty declarations.

  What has changed?

  • Update Java parser to allow semicolons as empty declarations.

  What is the user value, why is this change beneficial?

  • Very old Java code, and often code that has been written by C/C++ developers, includes semicolons after type, function, and method declarations. Even though those semicolons are not needed, they are allowed and hence are now correctly handled.

v30849 (2023-08-04)

• FIXED Always use the new keyword to call a constructor for unit tests of Spring (Boot) components.

  What has changed?

  • Mark constructors of Spring (Boot) components as real constructors to use the correct instantiation during unit testing.

  What is the user value, why is this change beneficial?

  • Some functionality of classes that are marked as Spring (Boot) components should not be tested through integration tests but through unit tests. This change makes sure that such unit tests do not reuse a mock of the component, i.e. what would be done for an integration test, and also do not try to call the constructor like a static function, but instead now correctly use the new keyword to call the right constructor. Hence, unit tests for Spring (Boot) components are now always correctly generated and compiled as expected.

• NEW Mark classes that use the @Component Spring annotation to be regular components.

  What has changed?

  • Mark classes that use the @Component Spring annotation to be regular components.

  What is the user value, why is this change beneficial?

  • Marking classes that use the @Component Spring annotation to be regular components leads to them receiving auto-wiring and auto-mocking as integration tests. Hence, users have to type far less when generating the boilerplate using the test template functionality of Symflower.

v30843 (2023-08-04)

• NEW Include default value for parameters in integration tests for Spring Boot controllers if one is defined.

  What has changed?

  • Include default value for parameters in integration tests for Spring Boot controllers if one is defined.

  What is the user value, why is this change beneficial?

  • The default value of a parameter to a request in a Spring Boot controller handler is optional in the integration test. However, including it in the test code allows users to type less in case they need it, and makes the behavior explicit in tests that rely on it.

• NEW Support all simple value types, such as enums and "java.lang.CharSequence", for Spring Boot controller parameters and response bodies.

  What has changed?

  • Support all simple value types for Spring Boot controller parameters and response bodies.

  What is the user value, why is this change beneficial?

  • Symflower now supports all simple value types for Spring Boot controller parameters and response bodies. This allows Symflower to generate tests for even more scenarios.

• CHANGED Traverse request parameters of Spring Boot controllers only once.

  What has changed?

  • Restructure logic to traverse request parameters of Spring Boot controllers only once.

  What is the user value, why is this change beneficial?

  • This change reduces the analysis time of request parameters, making the generation of integration tests for Spring Boot controllers faster.

v30794 (2023-08-02)

• FIXED Parse object hash strings with less than 8 characters correctly in Java assertion failures.

  What has changed?

  • Correct regex to parse object hashes of Java to include sums with less than 8 characters.

  What is the user value, why is this change beneficial?

  • Previously, we did not show object hashes with less than 8 characters but instead reported that we could not parse an assertion failure. With this change, all valid object hashes can be parsed.

v30788 (2023-08-02)

• NEW Extended testing corpus to include even more repositories and functionalities.

  What has changed?

  • Extend the testing corpus with additional Spring Boot repositories to check a wider range of Spring Boot scenarios.
  • Extend testing corpus functionality by unit test execution checks per generated test template over the existing build tool, i.e. Gradle or Maven.

  What is the user value, why is this change beneficial?

  • Symflower's testing corpus is an internal collection of repositories that are tested with a wide range of functionality scenarios. These repositories are currently manually added, so if you want to see your public repository included, write to hello@symflower.com.

v30737 (2023-07-28)

• CHANGED Disable the generation of assertions that use reflection for test templates by default.

  What has changed?

  • Disable the generation of assertions that use reflection by default.

  What is the user value, why is this change beneficial?

  • Some users reported that assertions that use reflection are not useful for generated test templates. With this change, this generation has been disabled by default using the TestGeneration.AllowReflectionForAssertions configuration option.

• NEW Allow to disable assertions that use reflection through the TestGeneration.AllowReflectionForAssertions configuration item. This option is on by default.

  What has changed?

  • Allow to disable assertions that use reflection through the TestGeneration.AllowReflectionForAssertions configuration option.

  What is the user value, why is this change beneficial?

  • Some users reported that assertions that use reflection are not useful for generated test templates. Symflower uses reflection to assert internal values that are set but cannot be perfectly checked when no getter method is provided. However, the same functionality is used for test templates when a type does not provide an "equal" or another comparison method.

• CHANGED Do not show "tests could not be generated" for "on save" usage as this can spam the user.

  What has changed?

  • Disable the "tests could not be generated" error notification for "on save" usage.

  What is the user value, why is this change beneficial?

  • Users using the "on save" functionality to trigger source code analysis and generate tests on every save action should never receive unnecessary notifications.

v30710 (2023-07-27)

• CHANGED Update the language server to use the newest LSP version 3.17.4-next.0 instead of 3.17.2 for Visual Studio Code.

  What has changed?

  • Update the language server to use the newest LSP version 3.17.4-next.0 instead of 3.17.2 for Visual Studio Code.

  What is the user value, why is this change beneficial?

  • Using the latest LSP version allows us to drop some workarounds and implement newer features for Symflower. Since almost all Visual Studio Code users of Symflower keep an up-to-date version, we decided to update.

• CHANGED Log unmarshalling errors of language server initialization to actually see the cause in the extension log.

  What has changed?

  • Log unmarshalling errors of language server initialization.

  What is the user value, why is this change beneficial?

  • Unmarshalling errors of the language server, which is used for every editor, e.g. Visual Studio Code and IntelliJ IDEA, have been rare so far with Symflower. However, by logging them directly to the extension log, it is now directly possible for users to debug these problems on their own. Such problems are usually user configuration problems that are not yet automatically worked around by Symflower.

• CHANGED Update to Go 1.20.6

  What has changed?

  • Symflower is now compiled with Go 1.20.6 instead of 1.20.3.

  What is the user value, why is this change beneficial?

  • Fixes multiple security issues and bugs. Most users should not be affected.

v30706 (2023-07-27)

• BREAKING Do not generate test cases for hidden directories/files, Gradle/Maven wrappers, nor implementation files in testing directories, unless explicitly wanted.

  What has changed?

  • Change the default of generating test cases for every directory and file to ignoring hidden directories/files, Gradle/Maven wrappers, and implementation files that are in testing directories when generating with wildcards or globs.

  What is the user value, why is this change beneficial?

  • When generating tests for entire directories and their subdirectories, users are mostly only interested in tests for implementation code that is production-relevant. This change sets the default to ignore all files that are not part of such production-relevant code. However, a user can still explicitly generate tests for ignored files by explicitly listing them.

• CHANGED Parse files only once even when directory filters overlap.

  What has changed?

  • Previously, overlapping directory filters led to files being loaded multiple times, e.g. loading a/** and a/b/** led to a/b/** parsed twice. Now, files are parsed by going through a loader queue which makes sure that every individual directory and file is only looked at once. This is most noticeable when imports are loaded in parallel because now, directories and files are guaranteed to be looked at only once.

  What is the user value, why is this change beneficial?

  • Parsing files with a noticeable big amount of imports is now much faster since all files of imported packages are now guaranteed to be parsed only once. This also fixes the very rare problem that in case a file with syntax errors is parsed twice, that syntax errors are reported twice.

• CHANGED Look up the source directory of a Java project only once per workspace instead of every time an action is done.

  What has changed?

  • Previously, Symflower looked up the source directories of individual projects in a workspace every time it performed an action, e.g. generate test template or generate test suite. Now, the source directories are only loaded once for all actions.

  What is the user value, why is this change beneficial?

  • This change reduces the amount of CPU and time for every action of Symflower, leading to snappier test generation and more productivity for the developer.

v30659 (2023-07-24)

• FIXED Do not import the MockMvcRequestBuilders.param method.

  What has changed?

  • Do not import the MockMvcRequestBuilders.param method.

  What is the user value, why is this change beneficial?

  • An import for MockMvcRequestBuilders.param was accidentally added even though it is a method, i.e. it cannot be imported, which led to compiling errors on the user's side. Removing this import now leads again to Symflower-generated code compiling perfectly.

v30638 (2023-07-22)

• FIXED Don't choose test method names for generating Java tests that clash with methods inherited from "java.lang.Object".

  What has changed?

  • Append a "TODO" suffix to test method names in case the name clashes with a method name inherited from "java.lang.Object".

  What is the user value, why is this change beneficial?

  • Previously, test method names could clash with method names that were inherited from "java.lang.Object", e.g. "hashCode" and "toString". We no longer clash, making every method cleanly testable.

v30634 (2023-07-21)

• NEW Switch to the regular test template workflow when a test suite cannot be generated.

  What has changed?

  • In case a test suite action fails hard for any reason, we fall back to the regular test template workflow.

  What is the user value, why is this change beneficial?

  • When Symflower cannot generate a test suite, e.g. because information about a type is missing or a language feature is not supported by the analysis, we now switch to the test template workflow. This makes the test suite action useful for every user on every action since a user wants to have a test case anyway, i.e. we give the user a test case with all the information that is currently available.

• CHANGED State in error notifications first what the problem is and then where the problem happened to make collapsed notification messages more useful.

  What has changed?

  • Change error notifications by the language server to state the problem message first and the problem location second.

  What is the user value, why is this change beneficial?

  • Editors by default show notifications collapsed, i.e. only the first few words are shown. This results in the problem that notifications that start with the location of an error, e.g. the file location, only show the location instead of a useful error message right away. Users reported either that they did not see an error notification, because this led to overlooking notifications, or did not find the notifications with collapsed messages useful. From now on, all notifications are useful right away, whether collapsed or not. As an example, instead of privateMethod.java: privateMethod.privateFoo: function is private and therefore inaccessible for tests we now show Function is private and therefore inaccessible for tests. Function: privateMethod.privateFoo.

v30630 (2023-07-21)

• FIXED Avoid transpiling files more than once when we are loading the same file in parallel by multiple other files, e.g. through imports.

  What has changed?

  • Previously, Symflower did not check if files being loaded were already in the process of being loaded. With this change, we only load files once, even when there are multiple requests at the same time.

  What is the user value, why is this change beneficial?

  • Previously, we had a bug that resulted in sometimes transpiling the same files in a single action multiple times. This resulted in "redefined errors" that kept us from analyzing source code. This change fixes this problem, which results in more source code being analyzed with every action and more results being cached at the same time.

v30624 (2023-07-20)

• NEW For Spring Boot controller tests returning a JSON response, define an assert call with the JSON path for each response entry and field.

  What has changed?

  • Generate JSON assertions depending on the type for Spring Boot controller tests.

  What is the user value, why is this change beneficial?

  • Spring Boot controller tests that return a JSON response require a range of assert calls for every entry and field that is returned. The amount of asserts is dependent on the type and is cumbersome to type and get right. With this change, all asserts for entries and fields are generated, leaving the values the only thing to type, i.e. massively saving time when writing such tests. As an example, instead of .andExpect(jsonPath("$.<key>").value("<value>")) for a template of a JSON assertion, all entries and fields are generated as individual assertion calls, e.g. .andExpect(jsonPath("$[0].repositoryName").value("<value>")).

v30586 (2023-07-19)

• NEW Include request parameters of URIs for the mock setup of Spring Boot controller requests.

  What has changed?

  • Analyze the controller request URI for parameters and include them as parameters to the mock setup of Spring Boot controller requests.

  What is the user value, why is this change beneficial?

  • Spring Boot controller tests need a perfectly set up request object to reach the specific controller code under test. This change adds every value for the parameter needed to these URIs. Hence, writing tests for Spring Boot controllers is now far less time-consuming and error-prone. As an example, instead of this.mockMvc.perform(post("/owners/{ownerId}/edit") we now generate this.mockMvc.perform(post("/owners/{ownerId}/edit", 123).

v30572 (2023-07-18)

• NEW Use primitive literals, e.g. 123, instead of constructors for primitive Java wrapper types, e.g. new Integer(123) for readability and to not invoke linter warnings.

  What has changed?

  • Use primitive literals instead of constructors for primitive Java wrapper types.

  What is the user value, why is this change beneficial?

  • Users reported unnecessary warnings for Symflower-generated code for primitive Java wrapper type constructors. These can be easily avoided by using primitive literals. Some users might think that it would be better to use the "valueOf" function as suggested by the linter warning. However, those are equivalent to just using primitive types that are then auto-boxed to their wrapper types. This solution is optimized for readability and maintainability.

v30555 (2023-07-17)

• CHANGED Remove "no symbols to analyze" log entry as it is already stated by logging "found 0 symbols".

  What has changed?

  • Remove "no symbols to analyze" log entry.

  What is the user value, why is this change beneficial?

  • Logs must be kept clean to ensure readability for easier debugging. With this change we are removing a redundant log entry in case no symbol has been found to analyze.

v30544 (2023-07-14)

• CHANGED Rephrase the word "catastrophic" to "fatal" everywhere.

  What has changed?

  • Rephrase the word "catastrophic" to "fatal" everywhere.

  What is the user value, why is this change beneficial?

  • The word "catastrophic" sounded too extreme for some users. With this change, all instances have been replaced with "fatal" which should better indicate that nothing got damaged or deleted for users, it's just that Symflower did not work as expected. Still, if you see such an error, please let us know!

v30537 (2023-07-14)

• FIXED Exclude whitespaces for parsing the correct type for JUnit 5 assertion errors when executing unit tests.

  What has changed?

  • Ignore whitespaces when parsing types in assertion errors.

  What is the user value, why is this change beneficial?

  • Before this change, the output of executing unit tests had to be well formed all the time. With this change, the parsing of types of assertion errors is now more robust for all forms of spacing, i.e. types for assertion errors are now always correctly parsed.

v30511 (2023-07-13)

• NEW Initialize nested types that have a class type for test templates.

  What has changed?

  • Initialize nested types that have a class type for test templates.

  What is the user value, why is this change beneficial?

  • Before this change, parameters of initializations e.g constructors of classes that had a parameter of a class type were only initialized with null. With this change, these parameters are now initialized with their most likely constructors. Therefore, users have to type even less when using test templates to write new tests.

v30505 (2023-07-12)

• NEW Include org.springframework.hateoas package as valid media type constants to convert more string literals to constants in Spring Boot tests.

  What has changed?

  • Include org.springframework.hateoas package as valid media type constants.

  What is the user value, why is this change beneficial?

  • Media type string literals, e.g. "application/json", are automatically converted into constants, e.g. MediaType.APPLICATION_JSON_VALUE, for consistency and readability. With this change, even more constants are automatically applied.

v30501 (2023-07-12)

• EPIC Include request parameters e.g. necessary for forms, for Spring Boot controller tests according to the used request types.

  What has changed?

  • Include request parameters that have loaded types as param calls in Spring Boot controller tests for test templates.

  What is the user value, why is this change beneficial?

  • This change brings one of the most requested features regarding Spring Boot support. Requests often have parameters that need to be defined to reach certain parts of controller code. With this change, request parameters are included as param calls to the MVC request if the type of the request parameter is loaded. Hence, users now need to type far less for controller tests and can rely on Symflower to use the correct type to initialize every field of request parameters.

v30484 (2023-07-11)

• EPIC Initialize parameters and variables that have a class type with their most likely constructor in Java for test templates.

  What has changed?

  • Instead of generating "null", initialize all parameters and variables that have a class type with their most likely constructor, i.e. their easiest to use constructor.

  What is the user value, why is this change beneficial?

  • Feedback from Symflower users strongly indicated that parameters are expected to not be "null". This change builds upon this feedback and initializes all parameters and variables of test templates that have a class type with their easiest-to-use constructor if type information is available. This means much less typing for users when writing new tests, since such constructors often require additional parameters that would have required typing. Now all these initializations are automatically generated.

v30473 (2023-07-11)

• NEW Always forward generic type information, even if the types are unknown or unsupported, to generate code and tests with the user's types.

  What has changed?

  • Always forward generic type information even if the types are unknown or unsupported.

  What is the user value, why is this change beneficial?

  • Previously,unknown and unsupported generic types lost their generic entry, e.g. Page<Post> was only generated as Page when Post was unknown. This happened most often when dependencies were not fully loaded for the analyzed source code. With this change, generic types are now always forwarded to always include them in generated code, e.g. types in test templates now always include the full types that the users provided in their source code, even if unknown or unsupported.

v30436 (2023-07-05)

• NEW Always use constants of content types, e.g. MediaType.APPLICATION_JSON_VALUE, instead of string literals, e.g. "application/json", for content types in Spring Boot tests.

  What has changed?

  • Always convert string literals for Spring Boot tests to constants.

  What is the user value, why is this change beneficial?

  • Previously, Symflower directly used the content types provided by the source code. Now, content types are always converted to constants for consistency and readability.

• NEW Automatically detect if dependencies are not correctly installed upon text execution.

  What has changed?

  • Correctly parse invalid execution states for JUnit 4 and 5.

  What is the user value, why is this change beneficial?

  • Previously, executing tests only knew two execution states: failing or passing. With this change, executing tests now correctly report invalid states as well, e.g. in cases where dependencies are not correctly installed.

v30372 (2023-06-28)

• NEW Include model assertions of responses for Spring Boot controller tests when a model is expected.

  What has changed?

  • Include model assertions of responses for Spring Boot controller tests when a model is expected.

  What is the user value, why is this change beneficial?

  • Prior to this change, users had to add the assertions for an expected model if a Spring Boot controller test expected a model. Now, these assertions are automatically added for test templates which means less typing for new tests and a safety net to not forget to check the model.

v30356 (2023-06-28)

• NEW Include view assertion of responses for Spring Boot controller tests when a view is expected.

  What has changed?

  • Include view assertion of responses for Spring Boot controller tests when a view is expected.

  What is the user value, why is this change beneficial?

  • Before this change, users had to add the assertion for an expected view in case a Spring Boot controller test expected a view. Now this assertion is automatically added for test templates which means less typing for new tests as well as a safety net to not forget to check the view.

v30322 (2023-06-26)

• NEW Automatically include the correct content type for requests of Spring Boot controller tests.

  What has changed?

  • If the content type is known for Spring Boot controller tests, include it for creating a Spring Boot MVC request.

  What is the user value, why is this change beneficial?

  • Before this change, test templates generated Spring Boot MVC requests for controller tests with an empty content type. Now the content type is automatically read or implied by analyzing the available source code.

v30264 (2023-06-21)

• CHANGED Include more data when logging requests and responses of the language server in debug mode for easier debugging and reporting of problems.

  What has changed?

  • Include additional information for logging requests and responses of the language server.

  What is the user value, why is this change beneficial?

  • In cases where a problem involved the language server used in the editors, it was hard to query valuable information on what the actual problems were and how they could be solved. With this change, additional information is available through the debug mode which already allowed us to investigate some problems remotely.

v30261 (2023-06-21)

• NEW Spring Boot components based on types in springframework.data.*, e.g. springframework.data.repository.Repository, are now marked as dependencies, e.g. for auto-wiring.

  What has changed?

  • Mark Spring Boot components based on types in springframework.data.* as dependencies.

  What is the user value, why is this change beneficial?

  • With this change, almost all reported scenarios for Spring Boot auto-wiring are now done automatically even without loaded dependencies. Therefore, test templates now save even more typing for writing new tests but also work right away, even when dependencies are not fully loaded for resolve types.

• FIXED Forward all available type information of parent types, i.e. of inherited types, that do not have their dependencies available.

  What has changed?

  • Forward all available type information of parent types, even when they are marked as unknown or unsupported.

  What is the user value, why is this change beneficial?

  • Unknown or unsupported parent types are most often a result of not loaded dependencies and block further analyses and code generation. The most important case is generating integration tests for Spring Boot with a dependency that should be auto-wired. With this change, more scenarios are enabled for correct auto-wiring.

v30260 (2023-06-21)

• FIXED Only add new lines after generated member variables, i.e. auto-wiring, if needed.

  What has changed?

  • Only add new lines for newly generated member variables in additional scenarios. This change fixes all scenarios that we know of that previously had too many new lines.

  What is the user value, why is this change beneficial?

  • Symflower automatically formats newly generated source code according to the projects' and files' conventions. This change makes sure that generated member variables (i.e. auto-wiring) only have at most one new line for all scenarios that have been reported.

v30198 (2023-06-19)

• NEW Provide default values for arrays in Java test templates.

  What has changed?

  • Use non-zero/non-empty default values for arrays in Java test templates.

  What is the user value, why is this change beneficial?

  • Multiple user interviews showed that Symflower's test templates should provide non-zero/non-empty default values so that users have better examples for changing their tests if necessary.

• NEW Provide non-zero/non-empty default values for asserting Spring Boot's "RequestHeader" and "RequestBody" to give users examples.

  What has changed?

  • Use non-zero/non-empty default values for asserting Spring Boot's "RequestHeader" and "RequestBody".

  What is the user value, why is this change beneficial?

  • Multiple user interviews showed that Symflower's test templates should provide non-zero/non-empty default values so that users have better examples for changing their tests if necessary.

v30194 (2023-06-19)

• NEW Support Java's shift assignment operators.

  What has changed?

  • Add support for <<=, >>= and >>>= for Java.

  What is the user value, why is this change beneficial?

  • Java allows the use of left and right shift operators in assignments as a shortcut. Those operators are rarely seen but are very common with programs that do some form of math. Symflower can now fully analyze source code with these operators and generate test suites for such programs.

v30152 (2023-06-13)

• NEW Add a special non-empty-initialization for "java.time.LocalDate" type in Java's test templates.

  What has changed?

  • Add common code to allow the initialization of non-primitive types in Java for test templates.
  • Add a special case for "java.time.LocalDate" to use LocalDate.of as its initializer to showcase how the new non-zero/non-empty default values could behave.

  What is the user value, why is this change beneficial?

  • All non-primitive types in Java such as classes, enums, and interfaces until now have had "null" as their default value in test templates. With this change, "java.time.LocalDate" uses a call to LocalDate.of as its initialization. Other types will follow with coming iterations. This gives users examples on how types are initialized for tests. This has been one of the most requested features for Symflower's test templates.

v30095 (2023-06-06)

• NEW Use non-empty default value for the "java.lang.String" type in Java test templates.

  What has changed?

  • Migrated from empty default value for test templates in Java to non-empty default values for the "java.lang.String" type.

  What is the user value, why is this change beneficial?

  • Multiple user interviews showed that zero/empty values for types are OK for test templates, but that it would be useful to have good examples for values in test templates, i.e. non-empty value for the "java.lang.String" type.

v29985 (2023-05-25)

• NEW Transpile annotations of Java interfaces.

  What has changed?

  • Java allows interfaces to have annotations which are now considered in all analyses.

  What is the user value, why is this change beneficial?

  • Annotations of Java interfaces are now considered in all analyses of Symflower, i.e. generated test templates and test suites now have more information to generate better tests. This is specially the case for Spring Boot components such as repositories which would otherwise not be detected as dependencies.

• FIXED Only add one new line instead of two for added class members.

  What has changed?

  • Correctly parse new lines of class members to detect the new lines of member variables of classes.

  What is the user value, why is this change beneficial?

  • Multiple new lines are usually automatically removed by formatters in editors. However, there are exceptions where multiple new lines do exist. Additionally, there are users not using auto-formatters. No matter the scenario, Symflower no longer adds multiple new lines after member variable declarations, providing users with consistent formatting.

• EPIC Auto-wire dependencies i.e. services and repositories for tests of Spring Boot controllers.

  What has changed?

  • When Spring Boot controller usage is detected, dependencies are now auto-wired for the controller's tests.

  What is the user value, why is this change beneficial?

  • From now on, Symflower is adding more and more maintainability for the auto-wiring of Spring Boot dependencies so users do not need to manually maintain these dependencies. This change automatically adds auto-wiring of services and repositories to controller tests when they are missing.

v29981 (2023-05-25)

• NEW Use non-zero/non-empty default values for primitive types in Java test templates.

  What has changed?

  • Migrated from zero/empty default values for test templates in Java to non-zero/non-empty default values.

  What is the user value, why is this change beneficial?

  • Multiple user interviews showed that users would find it useful to have good example values in test templates rather than zero/empty values. Symflower's test templates now offer non-zero/non-empty values for primitive types.

v29980 (2023-05-25)

• FIXED Consistently use trailing slashes for all pages and links of https://docs.symflower.com and redirect if the slash is missing.

  What has changed?

  • Force trailing slashes to have consistent URLs on docs.symflower.com and redirect if trailing slash is missing.

  What is the user value, why is this change beneficial?

  • Some redirects on docs.symflower.com did not work because of missing trailing slash. All links and pages now work as expected.

v29937 (2023-05-25)

• NEW Prominently display Symflower's changelog in its documentation https://docs.symflower.com.

  What has changed?

  • Add Symflower's changelog to the main navigation of docs.symflower.com.

  What is the user value, why is this change beneficial?

  • What has been changed in Symflower and why is critical information that users want to know. By placing it in the menu in Symflower's official documentation, the changelog should be easier to find.

v29920 (2023-05-24)

• CHANGED Rename Symflower's actions Generate Tests for * to Generate Test Suite for * and Add Test Template for * to Generate Test Template for *.

  What has changed?

  • Symflower's actions have been renamed from Generate Tests for * to Generate Test Suite for * and from Add Test Template for * to Generate Test Template for * in all clients of Symflower.

  What is the user value, why is this change beneficial?

  • Multiple interviews with users have shown that the previous naming was confusing to some users regarding the difference between test templates and generated tests. With redoing the terminology, users (and especially new users) should have an easier time using Symflower. Existing users now have a clearer distinction of terminology.

v29890 (2023-05-23)

• NEW Report "on-save" events when Symflower's "on-save" functionality is enabled.

  What has changed?

  • Report event for "on-save" actions of Symflower.

  What is the user value, why is this change beneficial?

  • This allows us to identify problems that need to be fixed because they are blocking usage. Users are still fully anonymous and we do not report any source code.

v29885 (2023-05-23)

• EPIC Fully enabled type resolution for test template generation.

  What has changed?

  • Previously, only a minimal set of type resolution was enabled for test template generation. Now, type resolution is fully enabled for test template generation, i.e. test templates make full use of loaded types to generate better initializations, imports, calls, and assertions for generated test templates.

  What is the user value, why is this change beneficial?

  • This change allows a huge set of scenarios to make full use of loaded types, which results in far better initializations, imports, calls, and assertions for generated test templates. This results in far fewer compile errors in generated tests, if at all. Please let us know at hello@symflower.com in case a test template does not look as expected, and especially if a test template does not compile. The next iteration will bring a range of additional improvements to initialization, imports, and assertions.

v29846 (2023-05-22)

• FIXED Include "TODO" suffix for test function names and test names in case of duplicated tests of generated test suites.

  What has changed?

  • Apply test numeration before checking for already existing methods. This results in test function names and test names now having the "TODO" suffix after their ID/name.

  What is the user value, why is this change beneficial?

  • This change makes all tests, no matter if they have been generated via the test suite or the the test template action, have the "TODO" suffix at the very end in case their name already exists. This gives the user deterministic and consistent naming for all generated tests, i.e. user's can rely on tests having non-surprising names.

v29836 (2023-05-21)

• FIXED When tests templates have been generated, test reviews previously showed all existing tests and the tests of generated test suites in the virtual file.

  What has changed?

  • Do not overwrite the CLI arguments configuration layer on test template generation.

  What is the user value, why is this change beneficial?

  • Test reviews now again only show generated tests that are relevant to the current context of the user.

v29826 (2023-05-21)

• FIXED Make sure Symflower is only deinitialized once when closing all projects in JetBrains editors.

  What has changed?

  • Make sure the LS in IntelliJ-based editors is always de-initialized on closing all projects by serializing their closing.

  What is the user value, why is this change beneficial?

  • Closing JetBrains editor windows now always successfully exits all Symflower processes.

• FIXED Allow the language server in JetBrains editors to only be initialized once for all editor windows.

  What has changed?

  • Make sure the language server setup procedure in IntelliJ-based editors is only executed once.

  What is the user value, why is this change beneficial?

  • Lots of users saw the exception "Language server already running" when installing or updating Symflower when they had multiple windows open in JetBrains editors beginning with version 2023. With this change, these problems are now completely gone.

v29812 (2023-05-17)

• NEW Show notification for manual actions on inaccessible (e.g. private) functions.

  What has changed?

  • Previously, users received a notification that no results (e.g. no tests) could be generated with an error message about unsupported private modifiers. Now, actions on inaccessible symbols show a valuable notification on why an action had no results.

  What is the user value, why is this change beneficial?

  • Private modifiers on types, functions, and methods result in inaccessible code for tests, e.g. a private method cannot be tested with JUnit. This is usually obvious to users when they investigate their own code, leading to changes in modifiers. However adding a notification that specifically addresses this problem helps to identify the problem faster and lets users stay in the flow.

v29805 (2023-05-17)

• FIXED Consistently build MacOS binaries of Symflower without "libobjc.A.dylib" as dependency.

  What has changed?

  • A linker bug of our C/C++ compilers resulted in adding "libobjc.A.dylib" as a dependency which is not needed at all.

  What is the user value, why is this change beneficial?

  • Keeping dependencies to a minimum helps to fix and port Symflower faster to newer MacOS versions.

v29741 (2023-05-15)

• EPIC Symflower's documentation is now public on https://docs.symflower.com.

  What has changed?

  • Until now, Symflower only had internal documentation, documentation on marketplaces, and the CLI help. The new documentation website https://docs.symflower.com allows for more in-depth documentation.

  What is the user value, why is this change beneficial?

  • The new documentation website https://docs.symflower.com is continuously updated and allows users to find documentation on Symflower's functionality, real world examples in the form of tutorials, and technical information. Let us know at hello@symflower.com what documentation you want to see next.

v29716 (2023-05-12)

• CHANGED Optimized initialization of workspace configurations when file path filters are used.

  What has changed?

  • Using file path filters resulted in multiple reads of the same root-configuration files. All configuration files are now only read once.

  What is the user value, why is this change beneficial?

  • Every action performed with Symflower such as generating test suites and test templates is now slightly faster. Projects with bigger configuration files are now especially faster.

v29694 (2023-05-11)

• FIXED Avoid crashing in rare scenarios when checking a Java identifier as a function that is not a function.

  What has changed?

  • Previously, a few scenarios crashed the source code analysis when an identifier was used as a function even though it is not a function, e.g. it is a class.

  What is the user value, why is this change beneficial?

  • Symflower is now more stable when analyzing source code during typing, i.e. unfinished versions of user programs.

v29634 (2023-05-10)

• FIXED Only import "github.com/stretchr/testify/assert" for generated Go test suites and Go test templates if needed.

  What has changed?

  • Previously "github.com/stretchr/testify/assert" was always imported, even if it was not used. Now, this import is only done if needed.

  What is the user value, why is this change beneficial?

  • Go test suites and Go test templates that do not require the "assert" package always compile right away without any additional steps.

• FIXED CLI arguments now always overwrite environment variables, and environment variables now always overwrite settings of files and defaults.

  What has changed?

  • Previously, some Gradle, Maven, and Symflower-related settings could not be overwritten by CLI arguments nor environment variables. Now, all settings are overwritten as expected.

  What is the user value, why is this change beneficial?

  • Overwriting settings via CLI arguments and environment variables now just works as expected.

• FIXED Do not try to generate Go tests that require reflection, when reflection is disabled.

  What has changed?

  • Previously, some tests have been generated for Go source code that did not pass because they required reflection to set values. However, when reflection is disabled, those reflection accesses were not generated, leading to generated tests that fail.

  What is the user value, why is this change beneficial?

  • Disabling reflection now only generates Go tests that pass in scenarios that previously would have required reflection.

• NEW Support language-specific settings

  What has changed?

  • Previously, special configuration items had to be used for specifying language-specific settings. Now, the same settings identifiers can be used over all languages with language annotations.

  What is the user value, why is this change beneficial?

  • Language-specific settings allows Symflower to support more complicated projects that often have directory-related language-specific settings.

v29573 (2023-05-05)

• FIXED Always create all directories of a test file's path if they do not exist.

  What has changed?

  • Previously, Symflower simply wrote a test file into a directory and expected the directory to exist. This failed in some scenarios for Gradle and Maven-related configurations.

  What is the user value, why is this change beneficial?

  • Test files should now always be written even if their directories do not exist yet. Such scenarios do not result in error notifications anymore.

• NEW Allow to combine multiple configuration files of Gradle, Maven and Symflower depending on their path.

  What has changed?

  • Enable multi-layered configurations for Java and Symflower-related configuration files.

  What is the user value, why is this change beneficial?

  • This change allows inheritance of configurations from parent directories. In the next iterations, more configurations will be added to Symflower to fully support all sub-project scenarios.

v29554 (2023-05-04)

• FIXED Allow to call the "jar" binary under Windows to extract Maven dependencies.

  What has changed?

  • Make calling the "jar" binary OS-independent for the JAR extraction of Maven dependencies. So far, this has caused a problem primarily on some Windows variants.

  What is the user value, why is this change beneficial?

  • Maven dependencies are needed to resolve all the source code of a project. Hence, with this change, more source code can be analyzed by Symflower, enabling more tests to be generated.

• FIXED Identify compilation errors with a special notification when a manual action fails.

  What has changed?

  • Identify compilation errors in the language server with a special notification when a manual action fails. Previously, the language server simply said to look into the log because of an internal error.

  What is the user value, why is this change beneficial?

  • When a manual action such as generating test suites and test templates fails, it is important to know how to fix it. Compilation errors usually need to be fixed by users. Identifying them with a special notification greatly reduces the time since the user does not need to look into Symflower's log.

• CHANGED Printed compile errors of Go source code, such as syntax errors and unknown types, now have relative paths when reported in the CLI.

  What has changed?

  • Trim the workspace path when reporting Go problems to print relative instead of absolute file paths.

  What is the user value, why is this change beneficial?

  • Relative file paths have far fewer characters and hence the context for reading CLI outputs is greatly reduced for the user.

• FIXED When printing a summary report to the user via the CLI, do not count user-related errors such as syntax errors toward potential problems.

  What has changed?

  • Do not count user-related errors towards potential problems, but represent them as their own metric.

  What is the user value, why is this change beneficial?

  • The printed summary of the CLI now divides between potential problems that are due to Symflower's source code analysis and test generation, and user errors such as syntax errors. This gives users a quick glimpse into the state of an analysis.

• NEW Implement "_" (underscore) as a reserved keyword for Java.

  What has changed?

  • Implement "_" (underscore) as a reserved keyword for Java.

  What is the user value, why is this change beneficial?

  • The underscore character has a special meaning in Java. It is now identified by Symflower as a reserved keyword.

• FIXED Allow unsupported code in a multi-value-assignment of Go source code to pass all semantic checks.

  What has changed?

  • Multi-value-assignments that have unsupported code were previously partly unhandled. With this change, we now support all forms of multi-value-assignments.

  What is the user value, why is this change beneficial?

  • Unsupported source code is marked by Symflower e.g. when a dependency is not loaded yet or a user has a temporary compile error during typing. Symflower can still generate test suites and test templates with such unsupported code. However, such unsupported code must pass all the semantic checks of Symflower. This is now the case for multi-value-assignments which allow users to generate test suites and test templates for more source code even while typing.

• FIXED Print non-semantic compile errors of Go source code (such as syntax errors) as user errors.

  What has changed?

  • Print non-semantic compile errors of Go source code always as user errors. Previously, such errors were printed as internal errors, which is not correct as they are not related to Symflower.

  What is the user value, why is this change beneficial?

  • Even though we recommend that users are using their native compiler functionality, e.g. "go build", Symflower can report compile errors. Those are now marked correctly as user related errors.

• NEW Automatically report soft failures that make an analysis exit.

  What has changed?

  • Report soft failures that make an analysis exit.

  What is the user value, why is this change beneficial?

  • This allows us to identify problems that need to be fixed because they are hindering usage. Users are still fully anonymous and we do not report any source code.

v29517 (2023-05-02)

• NEW Automatically report hard failures.

  What has changed?

  • Report hard failures that let the Symflower exit.

  What is the user value, why is this change beneficial?

  • This allows us to identify problems that need to be fixed because they are breaking usage completely. Users are still fully anonymous and we do not report any source code.

v29470 (2023-04-28)

• FIXED Open files in existing split group instead of creating a new split group. (applies to Android Studio 2023, IntelliJ IDEA 2023, GoLand 2023)

  What has changed?

  • The API behavior of IntelliJ-based editors changed beginning with version 2023, which resulted in opening additional split groups.

  What is the user value, why is this change beneficial?

  • Opening a new split group when generating test suites or generating test templates now gives a deterministic behavior, i.e. open test files are reused.

v29456 (2023-04-27)

• CHANGED Send telemetry events synchronously for the CLI but asynchronously for the language server.

  What has changed?

  • Send telemetry events synchronously for the CLI but asynchronously for the language server. Previously, events have been sent synchronously.

  What is the user value, why is this change beneficial?

  • This allows editors to never be blocked because of a slow internet connection. Hence, user workflows are not disturbed

• NEW Report generating test suites and generating test templates as manual actions.

  What has changed?

  • Report generating test suites and generating test templates as manual actions.

  What is the user value, why is this change beneficial?

  • This allows us to identify how Symflower is used by users and if problems occur due to specific manual actions. Users are still fully anonymous and we do not report any source code.

v29445 (2023-04-27)

• NEW Automatically select a "TODO" suffix to make editing faster.

  What has changed?

  • Suffixes are automatically selected in editors.

  What is the user value, why is this change beneficial?

  • Automatically selecting the "TODO" suffix for function names and test names allows for much faster editing and a continuous test flow.

• NEW Append the suffix "TODO" to test functions and names if the same function or test name already exists.

  What has changed?

  • Append the suffix "TODO" in case Symflower would generate a duplicate test case name.

  What is the user value, why is this change beneficial?

  • This change allows users to clearly identify if they need to reword a test case name. Additionally, this avoids syntax errors by default, as test files would not compile if multiple functions had the same name.

v29417 (2023-04-26)

• CHANGED Compound all recovered errors with previous errors to preserve the integrity of error information.

  What has changed?

  • Recovered errors are now compounded inside of previously raised errors.

  What is the user value, why is this change beneficial?

  • This allows us to identify a chain of problems (if it exists) instead of just the last recovered error.

v29391 (2023-04-25)

• NEW Include a session ID in telemetry messages.

  What has changed?

  • All telemetry messages that are reported now include a session ID to group reported problems.

  What is the user value, why is this change beneficial?

  • This allows us to identify if a problem is most likely happening because of a previous event. Users are still fully anonymous and we do not report any source code.

v29388 (2023-04-25)

• CHANGED Let version information of Symflower use log entries instead of simply printing them to STDOUT and STDERR.

  What has changed?

  • All outputs of Symflower are now forwarded as log entries instead of simply printing to STDOUT and STDERR.

  What is the user value, why is this change beneficial?

  • This change makes the output of Symflower consistently use log entries that can be easily filtered. This is especially useful for embedding Symflower into other programs and in CI scenarios.

• FIXED Use the correct new-line characters for all Windows log entries.

  What has changed?

  • Use the correct new-line characters for all Windows log entries.

  What is the user value, why is this change beneficial?

  • Some log entries used the Unix-specific new-line character, which made logging under Windows inconsistent. This change makes all log entries consistently use the same new-line characters under Windows.

• NEW Identify if Symflower is running in a container.

  What has changed?

  • All reported telemetry messages now include a flag if Symflower was running inside of a container.

  What is the user value, why is this change beneficial?

  • This allows us to identify if features and problems in CIs should be prioritized. Users are still fully anonymous and we do not report any source code.

• NEW Include a Symflower-unique machine ID in telemetry messages.

  What has changed?

  • All telemetry messages that are reported now include a Symflower-unique machine ID to anonymously identify users.

  What is the user value, why is this change beneficial?

  • This allows us to identify which features and problems need to be prioritized because they apply to a bigger user base. Users are still fully anonymous and we do not report any source code.

v29313 (2023-04-21)

• NEW Automatically report fatal crashes of Symflower's language server in the editors and the CLI binary.

  What has changed?

  • All fatal crashes of Symflower's language server in the editors and the CLI binary are automatically caught and reported.

  What is the user value, why is this change beneficial?

  • Crashes of Symflower happen rarely and are very hard to debug without sufficient information about the crash. Automatically sending such crashes home allows us to fix them sooner for all users. Please note that we are not sending home any information about the user's source code, only problems of our own binary.

v29285 (2023-04-20)

• NEW Allow language-specific settings for all configuration items.

  What has changed?

  • Migrate configuration store to allow for language-specific settings. The changes for the users are scheduled for a later iteration.

  What is the user value, why is this change beneficial?

  • An upcoming change will enable users to set configuration items language-specific. This change migrates the backend, so we can identify problems for the automatic-configuration first.

v29265 (2023-04-19)

• CHANGED Minimize initializations of workspace and project configurations.

  What has changed?

  • Minimize initializations of workspace and projects configurations to read in file-based configurations only once when they are first needed.

  What is the user value, why is this change beneficial?

  • Initialization of Symflower's language server in the editors and all actions are now slightly faster and take less IO.

v29257 (2023-04-19)

• CHANGED Optimized handling and storage of workspace and project configurations.

  What has changed?

  • Optimized handling and storage of workspace and project configurations. This is a prerequisite for the configuration changes that are coming with the next iterations to fully cache all configurations.

  What is the user value, why is this change beneficial?

  • Initialization of Symflower's language server in the editors and all actions are now slightly faster, take less IO and take less memory.

v29162 (2023-04-13)

• CHANGED More efficient handling for file and symbol filters.

  What has changed?

  • Remodelled how file and symbol filters are forwarded.
  • File and symbol filters are now computed only once per analysis.

  What is the user value, why is this change beneficial?

  • File and symbol filtering are now more efficient regarding CPU, memory and IO. This makes every editor action more efficient.

v29112 (2023-04-11)

• CHANGED Extended benchmarks for common scenarios for test template generation.

  What has changed?

  • Added more common scenarios for benchmarking test template generation.
  • Extended monitoring of test template generation performance for CPU/IO/memory to all operating systems.

  What is the user value, why is this change beneficial?

  • Every scenario added to the benchmark suite of Symflower guarantees that execution time and used resources stay under specific thresholds. Our suite is now much more exhaustive. Please mail scenarios for test template generation that take longer than 1 second to hello@symflower.com, so we can analyze how to make them blazing fast.

v29032 (2023-04-06)

• REMOVAL Remove "predefine" variables from the common configuration.

  What has changed?

  • Removed "predefine" variables from the common configuration, i.e. for Go and Java.

  What is the user value, why is this change beneficial?

  • Predefine variables are only useful for the analysis of C-like languages, they are not useful for Go and Java. Removing them from the common configuration is a clean up of potentially confusing configuration items.

v28975 (2023-04-05)

• NEW Forward Symflower installations and updates as a metric.

  What has changed?

  • We are now collecting when Symflower is installed or updated.

  What is the user value, why is this change beneficial?

  • Having these metrics allows us to know how Symflower users are installing and updating, e.g. in what frequency. This allows us to optimize when we do breaking changes such as deprecations.

v28961 (2023-04-04)

• CHANGED Upgraded to NodeJS 16.20.0

  What has changed?

  • Upgraded to NodeJS 16.20.0 instead of 14.20.0.
  • Updated all dependencies of Symflower's Visual Studio Code extension to the latest versions.

  What is the user value, why is this change beneficial?

  • Symflower's Visual Studio Code extension is now packed more efficiently and runs faster with less memory.
  • Additionally, sporadic problems with certain operating systems versions should be fixed. Most users should not be affected.

• CHANGED Update to Go 1.20.3

  What has changed?

  • Symflower is now compiled with Go 1.20.3 instead of 1.20.2.

  What is the user value, why is this change beneficial?

  • Fixes multiple security issues and bugs. Most users should not be affected.

v28922 (2023-04-03)

• CHANGED More efficient handling of project context

  What has changed?

  • Objects of a project's context are now grouped in memory.

  What is the user value, why is this change beneficial?

  • Source code analysis and generation is now slightly faster and creates less garbage, i.e. the GC does less work.

v28892 (2023-03-31)

• NEW Resolve types of Java annotations to allow for more precise analyses

  What has changed?

  • The types of Java annotations are now resolved and checked.

  What is the user value, why is this change beneficial?

  • Java annotations are used in almost every framework, e.g. Spring Boot, and hence play a fundamental role in how applications are implemented. Symflower now not just checks their package path, e.g. to generate test templates for Spring Boot controllers, but also resolves their types and validates if types are correctly used. This allows for deeper analyses in the coming iterations, i.e. more precise results and tests.

v28860 (2023-03-29)

• FIXED Show all compilation errors for Java

  What has changed?

  • So far, Symflower was very restrictive on showing compilation errors, since we assumed users were using native tools for compilation. However, compilation errors are still useful in fatal problems of Symflower where nothing is generated.

  What is the user value, why is this change beneficial?

  • Since all compilation errors are now shown by default, users have an easier time debugging problems when Symflower does not provide results.

• CHANGED Updated test template support for Spring Boot to 2.7.9

  What has changed?

  • Symflower now officially supports Spring Boot up to 2.7.9 for test templates

  What is the user value, why is this change beneficial?

  • All versions up to 2.7.9 of Spring Boot are now supported
  • Supporting new versions of Spring Boot by Symflower is now easier and we are already working on supporting version 3

• NEW Show progress of downloads in console and log outputs

  What has changed?

  • Symflower now textually shows the progress of downloads, e.g. for symflower update in console and log outputs

  What is the user value, why is this change beneficial?

  • Before, users had no way of knowing when a download would be finished. Now, they can see how much was already downloaded and an estimation on when the download will be finished.

v28764 (2023-03-27)

• CHANGED Updated support for Maven to 3.9.1

  What has changed?

  • Symflower now officially supports Maven up to 3.9.1

  What is the user value, why is this change beneficial?

  • All versions up to the currently latest Maven version are now supported
  • Supporting new versions of Maven by Symflower is now easier

• CHANGED Updated support for Gradle to 8.0.2

  What has changed?

  • Symflower now officially supports Gradle up to 8.0.2

  What is the user value, why is this change beneficial?

  • All versions up to the currently latest Gradle version are now supported
  • Supporting new versions of Gradle by Symflower is now easier

v28502 (2023-03-17)

• NEW Transpile and analyze all Java annotations.

  What has changed?

  • Before we only transpiled specific Java annotations. Now we transpile all of them.

  What is the user value, why is this change beneficial?

  • Transpiling all Java annotations allows us to add more specific analyses and infer more data to generate better tests and test templates.

• NEW Handle content types as method parameters for Spring controller tests.

  What has changed?

  • Symflower now generates calls to the "contentType" method when a method parameter of a Spring controller request method has a "RequestHeader" annotation for "Content-Type".

  What is the user value, why is this change beneficial?

  • Less typing and changing for the user since we are now handling content types as inputs for a Spring controller test templates.

• FIXED Forward empty string on calling "content" method for Spring controller integration test templates to avoid ambiguity.

  What has changed?

  • Before we called the "content" method for Spring controller integration test templates, which leads to ambiguity. Hence, the templates were not compiling by default.

  What is the user value, why is this change beneficial?

  • Less typing and changing for the user since we are now always generating valid "content" calls.

v28319 (2023-03-12)

• NEW Print more information on initialization into the log on info and debug log levels.

  What has changed?

  • Before we hid lots of information during initialization. Now we forward them when the info or the debug log levels are used, depending on the entries.

  What is the user value, why is this change beneficial?

  • More information can help to identify and debug problems faster for the user and when reporting bugs.

• NEW Forward old Symflower version before an update as a metric.

  What has changed?

  • We are now collecting the Symflower version that existed before an update as a metric when metrics are sent.

  What is the user value, why is this change beneficial?

  • Having this metric allows us to know how Symflower users are updating, e.g. in what frequency. This allows us to optimize when we do breaking changes such as deprecations.

v28291 (2023-03-10)

• EPIC Migrate from JavaParser to Tree-sitter for parsing Java files for massive performance improvements.

  What has changed?

  • Previously we used JavaParser to parse Java source code. However, it was very slow for continuously parsing files while the user was typing (>250ms).
  • Symflower now uses Tree-sitter, as a generic parser generator and incremental parsing library, currently enabled for Java. Which is much faster (<10ms) in parsing single Java files, because Tree-sitter is much faster and we do not have to call an external process.

  What is the user value, why is this change beneficial?

  • The switch to Tree-sitter makes parsing files often take less than 1% of the time than before. Some benchmarks even have a speedup over over 20x, one has 36.675x.
  • If you want to learn more, take a look at our blog post Tree-sitter - the holy grail of parsing source code.

• CHANGED Do not require a Java binary for analyzing Java source code.

  What has changed?

  • With migrating to Tree-sitter (away from JavaParser) we can now analyze source code without the need of a Java binary.

  What is the user value, why is this change beneficial?

  • Symflower works now out of the box with more environments for analyzing source code and hence generating tests.

• CHANGED Analyse Java files that have paths with directories that have forbidden characters.

  What has changed?

  • With migrating to Tree-sitter (away from JavaParser) we can now finally analyze files that have directories in their path that have forbidden characters for package names, e.g. "hyphens-are-forbidden".

  What is the user value, why is this change beneficial?

  • It happens that users move projects and files into directories that have forbidden characters in their names. Since we are now supporting analyzing source code no matter the directory names, the user has to care less about where to put files.
  • Marking directory names with forbidden characters should be part of a convention rule, not of the analyzing tooling.

• FIXED Report file, line and column locations for leave-node problems such as "illegal modifiers" in Java.

  What has changed?

  • Previously we did not report file, line and column locations for some syntax errors, especially for leave-nodes.

  What is the user value, why is this change beneficial?

  • In case the user does not have a language tool integrated that spots syntax errors, we now report such errors. This is especially useful since such errors are usually the reason why we cannot analyze source code and, hence, also not generate tests.

v28278 (2023-03-09)

• CHANGED Update to Go 1.20.2

  What has changed?

  • Symflower is now compiled with Go 1.20.2 instead of 1.20.1.

  What is the user value, why is this change beneficial?

  • Fixes multiple security issues and bugs. Most users should not be affected.

v28181 (2023-03-06)

• CHANGED Symflower is now built using LLVM's Clang on Windows (Windows)

  What has changed?

  • Compiler of Symflower has changed from GCC to LLVM's Clang.

  What is the user value, why is this change beneficial?

  • All operating systems now use the same compiler. Hence, this allows us to have consistent results, e.g. test generation results, over all operating systems.
  • Allows to enable all optimizations and resulting in faster generated tests, especially for longer running generations. This will have a bigger impact in the coming iterations.
  • Allows us to move forward with supporting ARM64 on Windows.

• CHANGED Upgraded to LLVM 15

  What has changed?

  • Symflower is now compiled with LLVM 15 instead of 11.

  What is the user value, why is this change beneficial?

  • Symflower is now faster on all operating systems.
  • Resolves multiple bugs with older CPUs.

v28137 (2023-03-03)

• NEW In case there is no explicit content type, use JSON as the default for Spring controllers when either "RestController" or "ResponseBody" is used.

  What has changed?

  • When either the Spring annotation "RestController" or "ResponseBody" is used, and there is no explicit content type, we now set the default to JSON for test templates.

  What is the user value, why is this change beneficial?

  • Less typing and changing for the user since we are always using the correct content type.

• NEW Inherit content types of parent types Spring controller templates

  What has changed?

  • Test templates for Spring controllers methods now inherit the content type of their parent types, e.g. a handler method can inherit its content type from its class.

  What is the user value, why is this change beneficial?

  • Less typing and changing for the user since we are always using the correct content type.

v28103 (2023-03-02)

• CHANGED Always handle AST nodes without children as leaf-types for faster processing

  What has changed?

  • Certain AST nodes can theoretically have children but never do. Migrated all AST nodes that never have children to be leaf-types, which reduces processing time.

  What is the user value, why is this change beneficial?

  • Faster source code parsing and analysis.

• FIXED Handle ";" in Java as real statements so they are not automatically removed.

  What has changed?

  • Handle ";" in Java as real statements instead of ignoring them when changing files.

  What is the user value, why is this change beneficial?

  • Symflower is less disturbing when rewriting Java files. The empty statement ";" even though unnecessary, has meaning to users sometimes to document.

v28057 (2023-02-28)

• CHANGED Upgraded to Go 1.20

  What has changed?

  • Symflower is now compiled with Go 1.20.1 instead of 1.19.5.

  What is the user value, why is this change beneficial?

  • Fixed multiple CVEs.
  • This leads to 5% less memory usage and 3% faster execution on long-running test generations.

v28017 (2023-02-28)

• NEW Generate context-aware content type assertions for Spring controller templates

  What has changed?

  • Test templates now include assertions for the content type and expected content.

  What is the user value, why is this change beneficial?

  • Less typing for the users, since these necessary checks are now added automatically based on the existing code, e.g. a JSON response requires JSON checks.