Return to Answer

You don't test an enum declaration. You may test whether some function input/output contain the expected enum values.

The purpose of tests is to ensure the unit or component confirms to the requirements.

Requirements should be defined in terms of interface, behavior or input/output, it should not be defined in terms of the implementation at the language level.

A valid requirement for a function could for example be "the function should return the largest of two numbers". But it should not state implementation details like "the functions should contain an if-statement, which...". The reason is, we want to be able to change/refactor the implementation and have the tests confirm the function still works according to spec. If the test is coupled to the implementation, then we have to change the test if we change the implementation, which means we loose the benefit of the test (when you change both at the same time you might easily introduce an error) and we have twice as much work to do.

Testing if an enum declaration defines certain values, is testing the implementation, so this is bad. You want instead to test that certain enum values in input have the desired effect, or certain operations returns the expected enum values. If someone deletes one of the expected values from the enum declaration, then obviously the test will fail (or not compile, depending on the language), so you discover the error that way.

You don't test an enum declaration. You may test whether function input/output has the expected enum values. Example:

enum Parity { Even, Odd } Parity GetParity(int x) { ... } 

You don't write tests verifying then enum Parity defines the the names Even and Odd. Such a test would be pointless since you would just be repeating what is already stated by the code. Saying the same thing twice does not make it more correct.

You do write tests verifying GetParity say will return Even for 0, Odd for 1 and so on. This is valuable because you are not repeating the code, you are verifying the behavior of the code, independent of the implementation. If the code inside GetParity were completely rewritten, the tests would still be valid. Indeed the major benefits of unit tests is they give you freedom to rewrite and refactor code safely, by ensuring the code still works as expected.

But if you have a test which ensures an enum declaration defines the expected names, then any change you make to the enum in the future will require you to change the test also. This means it is not just twice as much work, it also mean any benefit to the unit test is lost. If you have to change code and test at the same time, then there is no safeguard against introducing bugs.

You don't test an enum declaration. You may test whether some function input/output contain the expected enum values.

The purpose of tests is to ensure the unit or component confirms to the requirements.

Requirements should be defined in terms of interface, behavior or input/output, it should not be defined in terms of the implementation at the language level.

A valid requirement for a function could for example be "the function should return the largest of two numbers". But it should not state implementation details like "the functions should contain an if-statement, which...". The reason is, we want to be able to change/refactor the implementation and have the tests confirm the function still works according to spec. If the test is coupled to the implementation, then we have to change the test if we change the implementation, which means we loose the benefit of the test (when you change both at the same time you might easily introduce an error) and we have twice as much work to do.

Testing if enum declaration declares have certain values, is testing the implementation, so this is bad. You want instead to test that certain enum values in input have the desired effect, or certain operations returns the expected enum values. If someone deletes one of the expected values from the enum, then obviously the test will fail (or not compile), so you discover the missing value.

You don't test an enum declaration. You may test whether some function input/output contain the expected enum values.

The purpose of tests is to ensure the unit or component confirms to the requirements.

Requirements should be defined in terms of interface, behavior or input/output, it should not be defined in terms of the implementation at the language level.

A valid requirement for a function could for example be "the function should return the largest of two numbers". But it should not state implementation details like "the functions should contain an if-statement, which...". The reason is, we want to be able to change/refactor the implementation and have the tests confirm the function still works according to spec. If the test is coupled to the implementation, then we have to change the test if we change the implementation, which means we loose the benefit of the test (when you change both at the same time you might easily introduce an error) and we have twice as much work to do.

Testing if an enum declaration defines certain values, is testing the implementation, so this is bad. You want instead to test that certain enum values in input have the desired effect, or certain operations returns the expected enum values. If someone deletes one of the expected values from the enum declaration, then obviously the test will fail (or not compile, depending on the language), so you discover the error that way.

You don't test an enum declaration. You may test whether function input/output contain the expected enum values.

The purpose of tests is to ensure the unit or component confirms to the requirements.

Requirements should be defined in terms of interface, behavior or input/output, it should not be defined in terms of the implementation at the language level.

A valid requirement for a function could for example be "the function should return the largest of two numbers". But it should not state implementation details like "the functions should contain an if-statement, which...". The reason is, we want to be able to change/refactor the implementation and have the tests confirm the function still works according to spec. If the test is coupled to the implementation, then we have to change the test if we change the implementation, which means we loose the benefit of the test (when you change both at the same time you might easily introduce an error) and we have twice as much work to do.

Testing if enum declaration declares have certain values, is testing the implementation, so this is bad. You want instead to test that certain enum values in input have the desired effect, or certain operations returns the expected enum values. If someone deletes one of the expected values from the enum, then obviously the test will fail (or not compile), so you discover the missing value.

You don't test an enum declaration. You may test whether some function input/output contain the expected enum values.

The purpose of tests is to ensure the unit or component confirms to the requirements.

Requirements should be defined in terms of interface, behavior or input/output, it should not be defined in terms of the implementation at the language level.

A valid requirement for a function could for example be "the function should return the largest of two numbers". But it should not state implementation details like "the functions should contain an if-statement, which...". The reason is, we want to be able to change/refactor the implementation and have the tests confirm the function still works according to spec. If the test is coupled to the implementation, then we have to change the test if we change the implementation, which means we loose the benefit of the test (when you change both at the same time you might easily introduce an error) and we have twice as much work to do.

Testing if enum declaration declares have certain values, is testing the implementation, so this is bad. You want instead to test that certain enum values in input have the desired effect, or certain operations returns the expected enum values. If someone deletes one of the expected values from the enum, then obviously the test will fail (or not compile), so you discover the missing value.