[jira] [Commented] (NIFI-10047) Refactor Groovy Tests to Java
[ https://issues.apache.org/jira/browse/NIFI-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767685#comment-17767685 ] David Handermann commented on NIFI-10047: - Thanks for asking about EncryptedSchemaRecordReaderWriterTest.groovy [~dstiegli1], I don't think it is worth converting to Java based on the previous approach. > Refactor Groovy Tests to Java > - > > Key: NIFI-10047 > URL: https://issues.apache.org/jira/browse/NIFI-10047 > Project: Apache NiFi > Issue Type: Epic > Components: Core Framework, Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > > A number of component modules include unit tests written in Groovy, while the > majority of tests are written in Java. Although Groovy has some advantages > for testing in particular, the lack of consistency across the framework > presents several maintenance challenges. > Groovy is similar enough to Java that it is possible to read with minimal > effort, but writing idiomatic Groovy requires a greater understanding of the > language. Some unit tests have leveraged Groovy to bypass method visibility > constraints, which violates standard class and method contracts. Compiling > and running tests in Groovy requires additional Maven configuration and > plugin execution, which contributes to the overall runtime of continuous > integration workflows. Using Java as the standard language for both > implementation and tests also makes it easier for contributors to maintain > and review changes. > For these reasons, existing Groovy test classes should be rewritten in Java, > with the exception of scripting components. > Refactoring and rewriting tests should be done in logical groups of work to > avoid missing important test functions in the conversion process. Some of the > modules with larger numbers of Groovy tests include the following: > * nifi-toolkit-encrypt-config > * nifi-toolkit-admin > * nifi-registry-core > * nifi-security-utils > * nifi-elasticsearch-restapi-processors > * nifi-elasticsearch-client-service > * nifi-framework-cluster > * nifi-framework-core > * nifi-web-api > * nifi-lookup-services > * nifi-standard-processors -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10047) Refactor Groovy Tests to Java
[
https://issues.apache.org/jira/browse/NIFI-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767228#comment-17767228
]
Daniel Stieglitz commented on NIFI-10047:
-
[~exceptionfactory] I noticed
{code:java}
nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/test/groovy/org/apache/nifi/provenance/EncryptedSchemaRecordReaderWriterTest.groovy{code}
was deleted as part of NIFI-12060. Would there still be a benefit to have that
converted to Java?
> Refactor Groovy Tests to Java
> -
>
> Key: NIFI-10047
> URL: https://issues.apache.org/jira/browse/NIFI-10047
> Project: Apache NiFi
> Issue Type: Epic
> Components: Core Framework, Extensions, NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
>
> A number of component modules include unit tests written in Groovy, while the
> majority of tests are written in Java. Although Groovy has some advantages
> for testing in particular, the lack of consistency across the framework
> presents several maintenance challenges.
> Groovy is similar enough to Java that it is possible to read with minimal
> effort, but writing idiomatic Groovy requires a greater understanding of the
> language. Some unit tests have leveraged Groovy to bypass method visibility
> constraints, which violates standard class and method contracts. Compiling
> and running tests in Groovy requires additional Maven configuration and
> plugin execution, which contributes to the overall runtime of continuous
> integration workflows. Using Java as the standard language for both
> implementation and tests also makes it easier for contributors to maintain
> and review changes.
> For these reasons, existing Groovy test classes should be rewritten in Java,
> with the exception of scripting components.
> Refactoring and rewriting tests should be done in logical groups of work to
> avoid missing important test functions in the conversion process. Some of the
> modules with larger numbers of Groovy tests include the following:
> * nifi-toolkit-encrypt-config
> * nifi-toolkit-admin
> * nifi-registry-core
> * nifi-security-utils
> * nifi-elasticsearch-restapi-processors
> * nifi-elasticsearch-client-service
> * nifi-framework-cluster
> * nifi-framework-core
> * nifi-web-api
> * nifi-lookup-services
> * nifi-standard-processors
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10047) Refactor Groovy Tests to Java
[ https://issues.apache.org/jira/browse/NIFI-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763919#comment-17763919 ] David Handermann commented on NIFI-10047: - Thanks for asking [~dstiegli1]. Those tests should be rewritten in Java. There are a number of Groovy scripts in src/test/resources/groovy that exercise the scripted capabilities, and those should remain in Groovy. However, for all the tests in src/test/groovy that you mentioned, those should be moved to Java. > Refactor Groovy Tests to Java > - > > Key: NIFI-10047 > URL: https://issues.apache.org/jira/browse/NIFI-10047 > Project: Apache NiFi > Issue Type: Epic > Components: Core Framework, Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > > A number of component modules include unit tests written in Groovy, while the > majority of tests are written in Java. Although Groovy has some advantages > for testing in particular, the lack of consistency across the framework > presents several maintenance challenges. > Groovy is similar enough to Java that it is possible to read with minimal > effort, but writing idiomatic Groovy requires a greater understanding of the > language. Some unit tests have leveraged Groovy to bypass method visibility > constraints, which violates standard class and method contracts. Compiling > and running tests in Groovy requires additional Maven configuration and > plugin execution, which contributes to the overall runtime of continuous > integration workflows. Using Java as the standard language for both > implementation and tests also makes it easier for contributors to maintain > and review changes. > For these reasons, existing Groovy test classes should be rewritten in Java, > with the exception of scripting components. > Refactoring and rewriting tests should be done in logical groups of work to > avoid missing important test functions in the conversion process. Some of the > modules with larger numbers of Groovy tests include the following: > * nifi-toolkit-encrypt-config > * nifi-toolkit-admin > * nifi-registry-core > * nifi-security-utils > * nifi-elasticsearch-restapi-processors > * nifi-elasticsearch-client-service > * nifi-framework-cluster > * nifi-framework-core > * nifi-web-api > * nifi-lookup-services > * nifi-standard-processors -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10047) Refactor Groovy Tests to Java
[
https://issues.apache.org/jira/browse/NIFI-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763914#comment-17763914
]
Daniel Stieglitz commented on NIFI-10047:
-
[~exceptionfactory] I would also like to get clarification what you meant by
{quote}
For these reasons, existing Groovy test classes should be rewritten in Java,
with the exception of scripting components.
{quote}
Did you mean by this to exclude all the following unit tests?
#
./nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/groovy/org/apache/nifi/lookup/script/TestSimpleScriptedLookupService.groovy
#
./nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/groovy/org/apache/nifi/lookup/script/TestScriptedLookupService.groovy
#
./nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/groovy/org/apache/nifi/processors/script/ExecuteScriptGroovyTest.groovy
#
./nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/groovy/org/apache/nifi/record/script/ScriptedReaderTest.groovy
#
./nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/groovy/org/apache/nifi/record/script/ScriptedRecordSetWriterTest.groovy
#
./nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/groovy/org/apache/nifi/reporting/script/ScriptedReportingTaskTest.groovy
> Refactor Groovy Tests to Java
> -
>
> Key: NIFI-10047
> URL: https://issues.apache.org/jira/browse/NIFI-10047
> Project: Apache NiFi
> Issue Type: Epic
> Components: Core Framework, Extensions, NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
>
> A number of component modules include unit tests written in Groovy, while the
> majority of tests are written in Java. Although Groovy has some advantages
> for testing in particular, the lack of consistency across the framework
> presents several maintenance challenges.
> Groovy is similar enough to Java that it is possible to read with minimal
> effort, but writing idiomatic Groovy requires a greater understanding of the
> language. Some unit tests have leveraged Groovy to bypass method visibility
> constraints, which violates standard class and method contracts. Compiling
> and running tests in Groovy requires additional Maven configuration and
> plugin execution, which contributes to the overall runtime of continuous
> integration workflows. Using Java as the standard language for both
> implementation and tests also makes it easier for contributors to maintain
> and review changes.
> For these reasons, existing Groovy test classes should be rewritten in Java,
> with the exception of scripting components.
> Refactoring and rewriting tests should be done in logical groups of work to
> avoid missing important test functions in the conversion process. Some of the
> modules with larger numbers of Groovy tests include the following:
> * nifi-toolkit-encrypt-config
> * nifi-toolkit-admin
> * nifi-registry-core
> * nifi-security-utils
> * nifi-elasticsearch-restapi-processors
> * nifi-elasticsearch-client-service
> * nifi-framework-cluster
> * nifi-framework-core
> * nifi-web-api
> * nifi-lookup-services
> * nifi-standard-processors
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10047) Refactor Groovy Tests to Java
[ https://issues.apache.org/jira/browse/NIFI-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763909#comment-17763909 ] David Handermann commented on NIFI-10047: - [~dstiegli1] The ConfigEncryptionTool class itself is also in need of refactoring, but that is beyond the scope of this test conversion. The test class is so large and involved, it may be better to address it as part of a larger rewrite effort. > Refactor Groovy Tests to Java > - > > Key: NIFI-10047 > URL: https://issues.apache.org/jira/browse/NIFI-10047 > Project: Apache NiFi > Issue Type: Epic > Components: Core Framework, Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > > A number of component modules include unit tests written in Groovy, while the > majority of tests are written in Java. Although Groovy has some advantages > for testing in particular, the lack of consistency across the framework > presents several maintenance challenges. > Groovy is similar enough to Java that it is possible to read with minimal > effort, but writing idiomatic Groovy requires a greater understanding of the > language. Some unit tests have leveraged Groovy to bypass method visibility > constraints, which violates standard class and method contracts. Compiling > and running tests in Groovy requires additional Maven configuration and > plugin execution, which contributes to the overall runtime of continuous > integration workflows. Using Java as the standard language for both > implementation and tests also makes it easier for contributors to maintain > and review changes. > For these reasons, existing Groovy test classes should be rewritten in Java, > with the exception of scripting components. > Refactoring and rewriting tests should be done in logical groups of work to > avoid missing important test functions in the conversion process. Some of the > modules with larger numbers of Groovy tests include the following: > * nifi-toolkit-encrypt-config > * nifi-toolkit-admin > * nifi-registry-core > * nifi-security-utils > * nifi-elasticsearch-restapi-processors > * nifi-elasticsearch-client-service > * nifi-framework-cluster > * nifi-framework-core > * nifi-web-api > * nifi-lookup-services > * nifi-standard-processors -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10047) Refactor Groovy Tests to Java
[
https://issues.apache.org/jira/browse/NIFI-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763898#comment-17763898
]
Daniel Stieglitz commented on NIFI-10047:
-
[~exceptionfactory] It seems the main class in nifi-toolkit-encrypt-config is
{code:java}
ConfigEncryptionTool.groovy{code}
which is already Groovy itself. Would it's corresponding unit test
{code:java}
ConfigEncryptionToolTest.groovy{code}
have to be refactored to Java? I noticed there are many cases in that unit test
where access to properties are exceeding its rights. It would necessitate many
changes to give properties private package scope. I know this was an issue when
working NIFI-11873. Please advise. Thanks!
> Refactor Groovy Tests to Java
> -
>
> Key: NIFI-10047
> URL: https://issues.apache.org/jira/browse/NIFI-10047
> Project: Apache NiFi
> Issue Type: Epic
> Components: Core Framework, Extensions, NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
>
> A number of component modules include unit tests written in Groovy, while the
> majority of tests are written in Java. Although Groovy has some advantages
> for testing in particular, the lack of consistency across the framework
> presents several maintenance challenges.
> Groovy is similar enough to Java that it is possible to read with minimal
> effort, but writing idiomatic Groovy requires a greater understanding of the
> language. Some unit tests have leveraged Groovy to bypass method visibility
> constraints, which violates standard class and method contracts. Compiling
> and running tests in Groovy requires additional Maven configuration and
> plugin execution, which contributes to the overall runtime of continuous
> integration workflows. Using Java as the standard language for both
> implementation and tests also makes it easier for contributors to maintain
> and review changes.
> For these reasons, existing Groovy test classes should be rewritten in Java,
> with the exception of scripting components.
> Refactoring and rewriting tests should be done in logical groups of work to
> avoid missing important test functions in the conversion process. Some of the
> modules with larger numbers of Groovy tests include the following:
> * nifi-toolkit-encrypt-config
> * nifi-toolkit-admin
> * nifi-registry-core
> * nifi-security-utils
> * nifi-elasticsearch-restapi-processors
> * nifi-elasticsearch-client-service
> * nifi-framework-cluster
> * nifi-framework-core
> * nifi-web-api
> * nifi-lookup-services
> * nifi-standard-processors
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
