reject if namespace contains string mismatched with env

[charlienegri]

Summary: if the namespace already contains a string mismatched with the env string, file should be rejected

Related issue:

228

Suggested reviewer(s):

Reviewer checklist:

• [ ] The headers of all files contain a reference to the repository license
• [ ] 100% test coverage of new code - meaning:
  • [ ] The overall test coverage increased or remained the same as before
  • [ ] Every function is accompanied with a test suite
  • [ ] Tests are both positive (testing that the function work as intended with valid data) and negative (testing that the function behaves as expected with invalid data, e.g., that correct exceptions are thrown)
  • [ ] Functions with optional arguments have separate tests for all options
• [ ] Examples are supported by doctests
• [ ] All tests are passing
• [ ] All names (e.g., files, classes, functions, variables) are explicit
• [ ] Documentation (as docstrings) is complete and understandable

The checklist is based on the S-ENDA conventions and definition of done (see General Conventions). The above points are not necessarily relevant to all contributions. In that case, please add a short explanation to help the reviewer.

[mortenwh]

@charlienegri - can you add the suggested tests?

[charlienegri]

@charlienegri - can you add the suggested tests?

so to clarify: I added the file tests/files/api/staging.xml to test the mismatch between env and namespace in testApiWorker_NamespaceRejectedIfWrongEnv, which your added lines break, do you want another test with a similar dev.xml files containing no.met.dev passed as passFile and where we test that trying to validate that in a production env fails?
passWorker._conf.env_string is supposed to be the environment discriminating string

[mortenwh]

do you want another test with a similar dev.xml files containing no.met.dev passed as passFile and where we test that trying to validate that in a production env fails? passWorker._conf.env_string is supposed to be the environment discriminating string

As mentioned in #232 - we must test that when the env is dev, we accept both no.met and no.met.dev namespaces, and similar for staging. In prod, we should only accept no.met. This is what needs to be tested, and the added lines are a start.

[charlienegri]

do you want another test with a similar dev.xml files containing no.met.dev passed as passFile and where we test that trying to validate that in a production env fails? passWorker._conf.env_string is supposed to be the environment discriminating string

As mentioned in #232 - we must test that when the env is dev, we accept both no.met and no.met.dev namespaces, and similar for staging. In prod, we should only accept no.met. This is what needs to be tested, and the added lines are a start.

I have now split the test in dev/staging, added another file to the tests batch, to test a .dev namespace
(it cannot be tested with passWorker._conf.env_string = "no.met.dev", that is supposed to be just the env string read from the config)
the fact that no.met would be accepted in dev and staging env is beyond the scope if this PR, isn't that covered by testApiWorker_NamespaceReplacement basically?

[mortenwh]

I have now split the test in dev/staging, added another file to the tests batch, to test a .dev namespace (it cannot be tested with passWorker._conf.env_string = "no.met.dev", that is supposed to be just the env string read from the config) the fact that no.met would be accepted in dev and staging env is beyond the scope if this PR, isn't that covered by testApiWorker_NamespaceReplacement basically?

No, not really. It should be explicit.

[charlienegri]

I have now split the test in dev/staging, added another file to the tests batch, to test a .dev namespace (it cannot be tested with passWorker._conf.env_string = "no.met.dev", that is supposed to be just the env string read from the config) the fact that no.met would be accepted in dev and staging env is beyond the scope if this PR, isn't that covered by testApiWorker_NamespaceReplacement basically?

No, not really. It should be explicit.

in testApiWorker_NamespaceReplacement we test that a namespace test.no is accepted in the environment yolo and ends up being test.no.yolo, you want to add explicitly the cases that no.met is accepted in dev/staging and ends up being no.met.dev/no.met.staging?