Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In-lining test output (as opposed to saving in files) #217

Open
kumar-ish opened this issue Dec 14, 2023 · 4 comments
Open

In-lining test output (as opposed to saving in files) #217

kumar-ish opened this issue Dec 14, 2023 · 4 comments

Comments

@kumar-ish
Copy link

Is there any ability to inline the results of the output that you're testing? e.g. expect tests in this blogpost have the result of the tests saved directly in the file itself.

This may be more desirable to see what's happened directly, instead of having a layer of indirection whereby you have to locate the file when you're just scanning to see what those test functions output, or have to delete all the expected output files. AFAICT there's nothing in the document to permit this, am I missing something or might there be an extension to this that allows for that?

@claremacrae
Copy link
Collaborator

Hi, one or two of the Approval Tests implementations in other languages have very recently started adding the ability to inline the approved text in source code.

It's not something available in the C++ implementation, however.

@kumar-ish
Copy link
Author

kumar-ish commented Dec 14, 2023

Is this something you'd be open to adding for the C++ version? If so, I can put together an implementation over the Christmas period (potentially, depending on how hard it is 😅). Thank you by the way, this library is great!

@claremacrae
Copy link
Collaborator

Thanks for the kind words.

Yes, I do think it would be worth adding.

In an ideal world, we would pair with @isidore on this, but I know that he's not available until mid-January - so if you wanted to start experimenting over Christmas, that would be much appreciated.

We would want its implementation and interface to end up being broadly consistent with that being added in the other in the other language implementations... So that would require a little background knowledge.

But I don't think that's critical in the first version - we can always, later on, refactor something that exists.

By far my biggest worry with this would be incorrectly overwriting the user's source code and them losing code though.

Again, we might be able to learn from what @isidore has done in other languages. But it would need serious tests for things like respecting the end-of-line characters in the original source file.

@isidore
Copy link
Member

isidore commented Dec 14, 2023

I would start here: https://github.com/approvals/ApprovalTests.Java/blob/master/approvaltests/docs/how_to/InlineApprovals.md

The 2 classes you needed to implement are:

  1. [InlineComparator]https://github.com/approvals/ApprovalTests.Java/blob/master/approvaltests/src/main/java/org/approvaltests/inline/InlineComparator.java). -> This is actually a namer + the wiring for reportering
  2. [https://github.com/approvals/ApprovalTests.Java/blob/master/approvaltests/src/main/java/org/approvaltests/inline/InlineJavaReporter.java]

Plus an option, 3rd

  1. (CodeParts)[https://github.com/approvals/ApprovalTests.Java/blob/master/approvaltests/src/main/java/org/approvaltests/inline/CodeParts.java]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants