Input class unit tests

[nakul680]

• added unit tests for simple keyword functions
• added eq method for SimpleKeyword class to compare simple keywords based on the keyword

[haneug]

From what I see it would be totally reasonable to have all the input tests in one test file (~100-200 lines of test). Also please add a marker unit for the unit tests so that we can run them separately with pytest -m unit in the CI

[haneug]

This is already a good start 👍
You should consider the following things moving forward:

• put the unit tests in their own sub folder so one can easily run only the unit tests, e.g., tests/unit/
• please make use of @pytest.mark.parametrize for similar tests that differ only in input data to reduce the number of tests and to get better control and cleaner overview over them. I commented one example and I hope that is already enough to get the gist.
• please try to make the unit tests more specific. In the integration tests (example tests for ORCA) we rely on ORCA and therefore we did not want to test too thoroughly but here we should be as specific as possible, e.g., instead of len(blocks) == 2, check set(blocks.keys()) == {BlockA, BlockB}
• every test should have a short docstring on what is tested.

[nakul680]

I added a eq() function for the ArbitraryString class for the purposes of testing , I'm not sure if this was the right away to go about it.

[haneug]

I like the addition of test_arbitrary_strings and the way you used parametrize. I just have a few minor comments and suggestions you could try:

• Please rename test_arbitray_strings.py to test_input_arbitrary_strings.py for consistency.
• In test_input_simple_keywords.py, you (almost) repeat the same parametrize three times. You could consider defining a single fixture with params instead and reusing it.
• If possible, I’d avoid hard-coding simple_keywords directly in tests. You should try to use fixtures or parameters where it is possible (I made some comments).
• For the docstrings, I’d avoid describing parameter-specific behavior (see my comments). As a general suggestion: try to keep them to short one-liners that describe the behavior under test, instead of repeating the function signature. I really liked how you did this in test_arbitrary_strings.py.

One last thing: please try to avoid force-pushing (if possible) and merge instead. A clean history make the review a bit easier :)

[timmyte]

Please remove the blanks in the documentation of strict = True.

Otherwise, thanks for adding the requested fixtures.
And I hope you can see the advantage of not xxx over len(xxx) = 0.

[timmyte]

Great. Nice

@nakul680
You can proceed to merge the PR, but please fix Hagen's last open requests. Just click on "Resolve conversation" when they are done.
Once done, please squash all your changes and to don't forget to add a closes #71 tag, to close the corresponding issue.

Other reviewer approved