You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Vladimir Sitnikov <si...@gmail.com> on 2019/03/06 20:30:59 UTC
JMeter resources vs type safety vs resources.PackageTest
Hi,
JMeter uses messages.properties as a ResourceBundle.
Then there's resources.PackageTest which has three types of tests:
1) testLang. It cross-checks if "language-specific" file like
messages_fr.properties has extra properties when compared with etalon
messages.properties
2) checkI18n which ensures all the translations are available in French
3) checkResourceReferences. It parses source java files and looks for
getResString("...") kind of patterns. The test there is to check if the key
looks sane (e.g. no spaces allowed), and it ensures that resource is
present.
Items #1 and #2 are trivial (those are just a cross-check of the
*.properties) files in "core" module.
The item #3 is more complicated as messages*.properties are located in
"core" module while the source code is scattered all over the place.
While I can duplicate "check resources" test in each module, however does
sound odd.
We store text-based keys, and we invent complicated checks to check
validity of the keys.
We have a strongly typed language, why don't we use types?
At the end of the day, "property keys" are like public API. We can't really
rename or remove the keys.
For instance, we could create Messages interface with relevant methods and
arguments.
Then it would be impossible to call "missing" method.
That approach is used in Calcite to specify exception messages:
https://github.com/julianhyde/hydromatic-resource
Resource interface:
https://github.com/apache/calcite/blob/7c905ff3263bcc6cec826789305f1be9fba0962e/core/src/main/java/org/apache/calcite/runtime/CalciteResource.java
Properties file:
https://github.com/apache/calcite/blob/7c905ff3263bcc6cec826789305f1be9fba0962e/core/src/main/resources/org/apache/calcite/runtime/CalciteResource.properties
Any thoughts?
Vladimir
Re: JMeter resources vs type safety vs resources.PackageTest
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 06.03.19 um 21:30 schrieb Vladimir Sitnikov:
> Hi,
>
> JMeter uses messages.properties as a ResourceBundle.
>
> Then there's resources.PackageTest which has three types of tests:
> 1) testLang. It cross-checks if "language-specific" file like
> messages_fr.properties has extra properties when compared with etalon
> messages.properties
> 2) checkI18n which ensures all the translations are available in French
> 3) checkResourceReferences. It parses source java files and looks for
> getResString("...") kind of patterns. The test there is to check if the key
> looks sane (e.g. no spaces allowed), and it ensures that resource is
> present.
>
> Items #1 and #2 are trivial (those are just a cross-check of the
> *.properties) files in "core" module.
> The item #3 is more complicated as messages*.properties are located in
> "core" module while the source code is scattered all over the place.
>
> While I can duplicate "check resources" test in each module, however does
> sound odd.
> We store text-based keys, and we invent complicated checks to check
> validity of the keys.
>
> We have a strongly typed language, why don't we use types?
> At the end of the day, "property keys" are like public API. We can't really
> rename or remove the keys.
As sebb noted, we can remove the keys, when we are no longer using it,
but you are right, that we should think carefully before doing that (has
it been done before?).
>
> For instance, we could create Messages interface with relevant methods and
> arguments.
> Then it would be impossible to call "missing" method.
> That approach is used in Calcite to specify exception messages:
> https://github.com/julianhyde/hydromatic-resource
Having glanced over it, it seems to be something I could like. But I
don't feel much pain with respect to properties at the moment -- apart
from the unfortunate copying of the utf-8 encoded files by IDEs.
Felix
>
> Resource interface:
> https://github.com/apache/calcite/blob/7c905ff3263bcc6cec826789305f1be9fba0962e/core/src/main/java/org/apache/calcite/runtime/CalciteResource.java
> Properties file:
> https://github.com/apache/calcite/blob/7c905ff3263bcc6cec826789305f1be9fba0962e/core/src/main/resources/org/apache/calcite/runtime/CalciteResource.properties
>
> Any thoughts?
>
> Vladimir
>
Re: JMeter resources vs type safety vs resources.PackageTest
Posted by Vladimir Sitnikov <si...@gmail.com>.
By the way, for now I just duplicated the below pattern all over the
place, so all the tests pass.
The only missing tests are "batch" tests (and some useful bits in
JMeterVersionTest)
public class ResourceKeyUsageTestJms extends ResourceKeyUsageTest {
// Test from the base class is used, so we just validate current module
}
Vladimir
Re: JMeter resources vs type safety vs resources.PackageTest
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb>Keys can be removed if code is refactored or dropped.
Plugins can still rely on the keys.
sebb> How does it work with other languages?
What do you mean by "how"?
hydromatic-resource uses the very same java.util.PropertyResourceBundle class.
Vladimir
Re: JMeter resources vs type safety vs resources.PackageTest
Posted by sebb <se...@gmail.com>.
On Wed, 6 Mar 2019 at 20:34, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> Hi,
>
> JMeter uses messages.properties as a ResourceBundle.
>
> Then there's resources.PackageTest which has three types of tests:
> 1) testLang. It cross-checks if "language-specific" file like
> messages_fr.properties has extra properties when compared with etalon
etalon ?
> messages.properties
> 2) checkI18n which ensures all the translations are available in French
> 3) checkResourceReferences. It parses source java files and looks for
> getResString("...") kind of patterns. The test there is to check if the key
> looks sane (e.g. no spaces allowed), and it ensures that resource is
> present.
>
> Items #1 and #2 are trivial (those are just a cross-check of the
> *.properties) files in "core" module.
> The item #3 is more complicated as messages*.properties are located in
> "core" module while the source code is scattered all over the place.
>
> While I can duplicate "check resources" test in each module, however does
> sound odd.
> We store text-based keys, and we invent complicated checks to check
> validity of the keys.
>
> We have a strongly typed language, why don't we use types?
> At the end of the day, "property keys" are like public API. We can't really
> rename or remove the keys.
Keys can be removed if code is refactored or dropped.
> For instance, we could create Messages interface with relevant methods and
> arguments.
> Then it would be impossible to call "missing" method.
> That approach is used in Calcite to specify exception messages:
> https://github.com/julianhyde/hydromatic-resource
>
> Resource interface:
> https://github.com/apache/calcite/blob/7c905ff3263bcc6cec826789305f1be9fba0962e/core/src/main/java/org/apache/calcite/runtime/CalciteResource.java
> Properties file:
> https://github.com/apache/calcite/blob/7c905ff3263bcc6cec826789305f1be9fba0962e/core/src/main/resources/org/apache/calcite/runtime/CalciteResource.properties
>
> Any thoughts?
How does it work with other languages?
> Vladimir