Codecov Report

Merging #85 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #85      +/-   ##
==========================================
+ Coverage   99.16%   99.17%   +<.01%     
==========================================
  Files           6        6              
  Lines         361      363       +2     
  Branches      116      117       +1     
==========================================
+ Hits          358      360       +2     
  Misses          1        1              
  Partials        2        2

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 07d2227...00645ac. Read the comment docs.

I understand the issue and how it can cause problems, but I'm not sure I see how the test adequately tests the problem. Can you explain?

My expectation for a test would be calling nrrd.write twice in such a way that the second nrrd.write has an odd or additional header value. This could be checked by calling nrrd.read and checking the header.

The purpose of the test was not to cover the mentioned bug (since it's already fixed). It was mostly to cover the case of having no header argument (Codecov complained). But you're right, there could be a point in testing repeated invocations.

Oh okay. With new features/bug fixes, the goal is to add a test that fails before the fix and succeeds after the fix. That way if someone adds some code down the line that messes this up, it will fail again. That should also fix the codecov problem too!

Hm, I'm a bit unsure how such a test case would look though. The thing is, there were no cases where this was actually breaking stuff since you were always overwriting the same fields with the same values. However, this is simply bad practice and could possibly lead to problems in the future.

A related thing, nrrd.write actually modifies the users copy of header:

header = {}
nrrd.write('file.nrrd', data, header)
print(header)

outputs

{'type': 'double',
 'endian': 'little',
 'dimension': 2,
 'sizes': [2, 2],
 'encoding': 'gzip'}

I don't know if this is intended.

Oh okay, I was curious whether there were any use cases where it would actually fail because we do overwrite the fields each time.

I think I'm fine with how it's setup then. The test you've added tests the if not header which is a good thing to do just in case.

Not sure if it's intended either, but I kinda like that functionality because then we know what parameters were saved after the fact. What do you think?

Maybe it's worth documenting that functionality to be safe.

I'll merge this PR tonight in case we want to continue having a conversation here.

Edit: Feel free to add yourself to the AUTHORS file if desired. I'm guessing this won't be your last PR 😄

Great! As for the header being mutable, I guess there could be some problems if users want to reuse the header object. However, as long as it is documented it should be fine I guess. There is some point in allowing the user to inspect the output header, as you mentioned.

I will take you up on that, thanks! 😃