Approvals::verify fails my test with an appended '\n' about approvaltests.cpp HOT 7 CLOSED

@curtnichols

That's a very fair question. I don't think we considered people who might have pre-created approval files, and for whom the extra character written out might be a problem.

If we were to change the behaviour of StringWriter, we would break a whole load of existing tests, so this will need some thought.

An idea for a temporary workaround: we recently made it quite easy to supply custom writer implementation, so perhaps you could try supplying your own writer class that didn't add the extra newline?

There is documentation here: https://github.com/approvals/ApprovalTests.cpp/blob/master/doc/Writers.md#top

from approvaltests.cpp.

I might try that.

Also, I need to look into writing the "received" file myself, as I'm generating it with an external program that can easily save to file itself. I suspect that might look like a custom Writer that can format the raw data.

from approvaltests.cpp.

I'm not sure about this, but if all your tests are using pre-created data and calling external programs, it's starting to sound to me like maybe the Python implementation of Approval Tests might give you what you need - https://github.com/approvals/ApprovalTests.Python

Assuming you stick with the C++ version, there's one potential pitfall with the naming of the pure virtual methods in ApprovalWriter that we have not documented:
https://github.com/approvals/ApprovalTests.cpp/blob/master/ApprovalTests/core/ApprovalWriter.h

The cleanUpReceived() method might sound like it is allowed to tweak the contents of the received file, but you should do any customisation of writing in write() - and in fact cleanUpReceived() is called to delete the received file on disk, if the test succeeded.

from approvaltests.cpp.

Oh - one more thought - is verifyExistingFile() any use to you:

from approvaltests.cpp.

verifyExistingFile sent me down a weird path, with an empty .approved.1 file being generated. Creating a custom writer is working nicely.

For context, the code under test is being executed from within the approval tests, the external program is just for converting binary image files into something diff-able.

from approvaltests.cpp.

The Reporter implementations that launch a diffing tool have to create an approved file, if it doesn’t yet exist, so that the diffing tool will launch and allow received to be copied to approved... Otherwise, most diff tools would just refuse to launch, saying one file did not exist.

So this is expected behaviour for most cases when first running a new Approvals test.

Glad you got the custom writer working!

Do you think this ticket needs any work now?

(I’ll probably leave it open anyway, as a reminder to document the things we talked about)

from approvaltests.cpp.

Thanks, I don't think I need anything more out of this issue.

from approvaltests.cpp.