{"action":"opened","issue":{"url":"https://api.github.com/repos/rosenbrockc/fortpy/issues/73","labels_url":"https://api.github.com/repos/rosenbrockc/fortpy/issues/73/labels{/name}","comments_url":"https://api.github.com/repos/rosenbrockc/fortpy/issues/73/comments","events_url":"https://api.github.com/repos/rosenbrockc/fortpy/issues/73/events","html_url":"https://github.com/rosenbrockc/fortpy/issues/73","id":114350199,"number":73,"title":"Simplify the Testing XML","user":{"login":"rosenbrockc","id":7817795,"avatar_url":"https://avatars.githubusercontent.com/u/7817795?v=3","gravatar_id":"","url":"https://api.github.com/users/rosenbrockc","html_url":"https://github.com/rosenbrockc","followers_url":"https://api.github.com/users/rosenbrockc/followers","following_url":"https://api.github.com/users/rosenbrockc/following{/other_user}","gists_url":"https://api.github.com/users/rosenbrockc/gists{/gist_id}","starred_url":"https://api.github.com/users/rosenbrockc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rosenbrockc/subscriptions","organizations_url":"https://api.github.com/users/rosenbrockc/orgs","repos_url":"https://api.github.com/users/rosenbrockc/repos","events_url":"https://api.github.com/users/rosenbrockc/events{/privacy}","received_events_url":"https://api.github.com/users/rosenbrockc/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/rosenbrockc/fortpy/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-10-30T20:28:11Z","updated_at":"2015-10-30T20:28:11Z","closed_at":null,"body":"Several of the fully unit-tested libraries have _very_ large XML files for certain modules. Much of this is duplicated settings that could equally well apply to many of the tests in the module. For example `eps` as a finite precision tolerance is ubiquitous in numeric codes; `verbose` or `seed` for random numbers will also be common to many of the tests. This is an enhancement specification for simplifying the XML needed to generate the tests. In many cases, we could reduce the tests to about 40% the number of lines.\r\n\r\n## Global Variable Assignments\r\n\r\nHave a new tag `<global>` in the `<fortpy>` namespace of the XML file. It can have two children:\r\n\r\n### `<value>` Tag\r\n\r\nThis has the same attributes as the `<value>` tag that is child of `<assignment>`. However, it can be applied to _any_ assignment in the unit tests of the same file. Any assignment would reference it with:\r\n\r\n```xml\r\n<assignment name=\"variable\" value=\"global:id\" />\r\n```\r\n\r\nwhere the `id` of the `<value>` tag is unique in the `<global>` list. We would pass in a global dictionary of the XML elements in the `<global>` tag. Each time such a `<value>` is encountered, we would just add its reference to the parent `<assignment>` tags values list.\r\n\r\n### `<defaults>` Tag\r\n\r\nAllows default attributes to be set that are common to _any_ other tag in the same file that usually mandates that attribute, but doesn't have it set. For example, the `<output>` tag requires a `folder` attribute to be set so that we know where the file lives. Instead, the `folder` attribute would be omitted and a `<defaults>` tag would be included in `<global>` as follows:\r\n\r\n```xml\r\n<defaults folder=\"../tests/utilities\" staging=\"../unittests/\" />\r\n```\r\n\r\nBefore the `ValueError` is thrown on any tag in the file during XML parsing, `fortpy` would first check the global `<defaults>` for an attribute with that value. The downside to such automation is that a person may forget why something isn't working only to discover that we were using the default values because they didn't specify the attribute at a lower level. I think the shorter files are worth the tradeoff; they could always just not use `<global>` if they are worried.\r\n\r\n## Automated Identifiers\r\n\r\nThere is a one-to-one correspondence between `<target>` and `<output>` tags (usually) and for most tests, only one parameter or variable is having its value checked. In such an instance, we should not require the `<output>` tag to have its identifier set and then `compareto` attribute on the `<target>` tag could be left out as well. We could just hook them up since there is only one way to do it.\r\n\r\nMost variable assignments have an `<assignment>` tag with a single `<value>` embedded in it. If there is only one value, the user should be allowed to leave out `identifier` on the `<value>` tag and the attribute `value` on the `<assignment>` tag since there is only one way to hook those up. If no value should be assigned, and the `<value>` tag is being kept for backup or working then an identifier on `<value>` would _prevent_ the auto-assignment of the `value` attribute.\r\n\r\nFor most unit tests, there is only one `<test>` tag. We should auto-assign the identifier of the test tag in this case to be `default`, set `timed=\"true\"` by default and set a default description such as \"No additional descriptors.\". Thus, only `cases` would need to be explicitly set if the test is run for multiple cases.\r\n\r\nFor the `<group>` tag that defines the unit tests, it should be sufficient to have `purpose=\"testing\"` on the tag. We could use the name of the `executable_test` as the default identifier for the group.\r\n\r\n## `<auto>` Tag\r\n\r\nMany of the unit tests have massive duplication of lots of attributes. For example, most tests store the input and output files in the same directory relative to the testing root. Most of the filenames have the same form (e.g. `sometest_varname.in.{}`). The `<auto>` tag allows such duplication to be swept under the guise of `$` as in this example:\r\n\r\n```xml\r\n\t<auto names=\"js.out, ebars.out, rms.out, err.out\">\r\n\t  <output file=\"bcs_reweight_$.logsum.{}\" />\r\n\t</auto>\r\n\t<auto names=\"eps, seed\"><assignment value=\"global:$\" /></auto>\r\n```\r\n\r\nThe first `<auto>` tag would create _four_ `<output>` tags that are all identical except that 1) for `file` the `$` would be replaced by the name in the comma-separated list; 2) `identifier` on each `<output>` would be set to the name from the comma-separated list.\r\n\r\nThe second `<auto>` tag would create variable assignments for both `eps` and `seed` and set their values to the `<global>` `<value>` tags with the identifiers of their names. \r\n\r\nFor the `<auto>` tags, we would perform a deep copy of the XML tag and then update only the relevant attributes for each kind of tag (either `name` or `identifier` depending on its purpose), and then replacing the `$` in each attribute in the child tag.\r\n\r\nOverall, this will make the tests much quicker to write and easier to read. It shouldn't take too long either."}}