Fix for field error handling bug

[loren-osborn]

This is a fix to a bug when error handling resulting from serializing fields containing closure values.

@dgsb, this should be ready to review now. This is a replacement for #847. It has two distinct commits intentionally:

• The first commit adds tests to identify the discovered issue in go test used in Travis CI.
  • This commit intentionally fails Travis CI to prove the bug is identified correctly.
• The second commit is a minimal fix to the issue.
  • I removed the refactoring from WIP: PLEASE LEAVE OPEN for now. Possible bugs? Refactoring highlighted a couple odd behaviors. #847 where the bug was identified.

[loren-osborn]

@dgsb, this should be good to go... I intentionally kept it simple. Let me know if you'd like any changes.

[loren-osborn]

@dgsb, @sirupsen, @stevvooe, want to let me know if this is what you wanted. It just adds a test for the newly-found bug, and then adds a fix for it.

The fix is simply string manipulation.

(FYI, my previous refactor of the big had been inaccurate... The old behavior was that if there was a new error, it appended only the last new error to the previous error list, otherwise, it emptied the error list.)

[dgsb]

Hello @loren-osborn, thanks for your contribution. The fix looks correct to me. However I find the test case too complicated to be easily maintainable in the future. May I request a few changes on it ? Please look at the review.

[loren-osborn]

I am working on an additional commit to add more granular independent tests, rather than removing the outer loop.

[loren-osborn]

@dgsb, I believe I addressed all of your concerns with my test code. Please let me know if you would like me to change anything else.

[dgsb]

@loren-osborn the fix is correct, but the test you've added is way too complicated to be usable when a modification on the source code cause its failure.
We really need to have simple (even simplistic) unit test so that we can easily identify what needs to be fixed when they are broken.

[loren-osborn]

I’m sorry to learn my tests are so fragile. I will work on making simple, clear, concise tests for this

[loren-osborn]

@dgsb, I don’t think I was able to simplify this very much, but think I made it a bit more clear. I also wasn’t able to find the fragility you alluded to. If you can tell me how the tests are failing, i’m happy to make them more robust.

[loren-osborn]

Just a note, the three failing commits are supposed to be failing, since the fix isn’t applied until the final commit.

[loren-osborn]

@dgsb, I took two more shots at clarifying, simplifying and fixing any fragility.

• I think it is definitely more clear than before.
• I did simplify the test some, by removing tests that are impossible to fail. but I also abstracted out some stuff, so I'm unsure if you feel it's an improvement.
• I'm still unsure how these tests are fragile. Please point me to something that breaks them, and I'm happy to improve them.

I'm open to any suggestions, but at this point I feel a bit like I'm going in circles. I'm happy with the state of the PR now, but please offer more specific feedback if you think it needs more work.

Thank you,
@loren-osborn

[loren-osborn]

I just noticed I left SlowTestWriter in this set of commits... it’s part of other pending changes i’m working on... Please review everything else, and I will have SlowTestWriter removed from this branch shortly.

Update: SlowTestWriter has been moved back to the correct commit on a different branch (and removed from this PR).

[loren-osborn]

Rebased this on master.

@dgsb, I would really appreciate any suggestions on how to make this suitable for merging. I made the tests as clear and simple as I was able, and am unaware of anything making them fragile. Please point any specifics you'd like me to change, and I'm happy to.

[dgsb]

@loren-osborn the fix itself is something like 10 lines, and all the tests around are something like 400 hundreds lines. I think it is too wide and not needed for this fix. Can you write the tests with something like 50 lines ?
We need somehow to new test functions, one which ensures the error field is kept upon a call to WithTime and one which checks the error field is kept after another WithField with correct parameter is called.
I think that's really all we need here.

[dgsb]

duplicate of #874