Mistakes in class names of many rule tests

[JHertz5]

Context

In the unit tests, test files for rules typically follow a convention where the name of the test class will follow the pattern test_X_rule, where X is the name of the production/rule group. For example, the tests in the subfolder subtype are called test_subtype_rule.

Problem

However, there are several cases where this rule is not followed and there is a mistake, e.g. in subtype/test_rule_005.py, where the class name test_type_definition_rule. This appears to be just human error (I've no doubt that I've personally introduced a significant number of these errors).

Here is a list of files in which I found mistakes in the class name.

File	Class name	Subfolder name
tests/array_constraint/test_rule_500.py	test_port_rule	array_constraint
tests/assert_statement/test_rule_002.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_003.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_004.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_005.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_100.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_101.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_102.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_400.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_500.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_501.py	test_assert_rule	assert_statement
tests/assert_statement/test_rule_502.py	test_assert_rule	assert_statement
tests/entity/test_rule_200.py	test_generic_rule	entity
tests/entity/test_rule_201.py	test_generic_rule	entity
tests/entity/test_rule_202.py	test_generic_rule	entity
tests/entity/test_rule_203.py	test_generic_rule	entity
tests/file_statement/test_rule_100.py	test_file_declaration_rule	file_statement
tests/function/test_rule_507.py	test_procedure_rule	function
tests/next_statement/test_rule_301.py	test_return_statement_rule	next_statement
tests/parameter_specification/test_rule_500.py	test_iteration_scheme_rule	parameter_specification
tests/procedure/test_rule_510.py	test_function_rule	procedure
tests/procedure/test_rule_511.py	test_function_rule	procedure
tests/report_statement/test_rule_001.py	test_assert_rule	report_statement
tests/report_statement/test_rule_002.py	test_assert_rule	report_statement
tests/report_statement/test_rule_100.py	test_assert_rule	report_statement
tests/report_statement/test_rule_101.py	test_assert_rule	report_statement
tests/report_statement/test_rule_300.py	test_assert_rule	report_statement
tests/subtype/test_rule_005.py	test_type_definition_rule	subtype
tests/subtype/test_rule_102.py	test_type_definition_rule	subtype
tests/subtype/test_rule_200.py	test_type_definition_rule	subtype
tests/subtype/test_rule_201.py	test_type_definition_rule	subtype
tests/subtype/test_rule_202.py	test_type_definition_rule	subtype
tests/type_mark/test_rule_500.py	test_type_definition_rule	type_mark
tests/whitespace/configuration/test_architecture_012.py	test	configuration
tests/whitespace/test_rule_001.py	test	whitespace
tests/whitespace/test_rule_002.py	test	whitespace
tests/whitespace/test_rule_200.py	test	whitespace

The information for the table was found using this script (it was generated by AI, the code is not high quality)

test.py

Solution

In my opinion, adding the production name to the class name is unnecessary duplication that adds very little value, adds work, and introduces a risk of creating mistakes. There are no other classes in these files, and the subfolder/module that the test is part of contains the production name, so there is no risk of not being able to figure out what is being tested. There are many rule tests that just call the class test_rule, and I think that we should apply this to all rule tests to avoid this duplication and remove the opportunity for these errors to be introduced in the future.

[JHertz5]

I've raised #1501 to resolve this issue. If the solution of changing all rule test class names is not preferred, I'm open to feedback.

[jeremiah-c-leary]

Afternoon @JHertz5 ,

In my opinion, adding the production name to the class name is unnecessary duplication that adds very little value, adds work, and introduces a risk of creating mistakes.

I completely agree.

For some reason when I started I thought it was necessary to have the production in the test name to keep things aligned. I do not believe I fully appreciated the scoping of the file in the test environment at the time.

I will get this merged to master.

btw, this is something I have wanted to do for a long time but never found the time to do it.

Regards,

--Jeremy