To correct my own stupidity: You were probably talking about diffing HTML in a meaningful way (that is, graphically in a web canvas). This makes total sense, of course.
Still, I wonder if separating the test running part and the approval part could be helpful, even though the prompts don’t actually block test execution. As soon as I have the time for it, I’ll test your approach and explore a separate workflow with separate test running and approval steps.
Right, we would pass you the full actual and expected values for you to do with as you please. This is how external/visual diff tools work with source control. And our use seems similar.
We’re happy to have you use our assert_value any way you’d like. But my advice would be to not worry too much about inspecting freshly generated new values for new tests for now. Makeup already works, and you have done a lot of work to make sure it works well. I would focus on thinking of good test cases and just accept whatever output they currently give. That way you capture the value of engineering and manual testing you have done already into automated tests.
The real benefit will come next, once you have a solid regression test suite to know when Makeup’s behavior changes. Those changes, will be worth inspecting in a lot of detail to see whether they’re good or bad.
And once you have this going for a while you will know the best way to serialize the data-HTML or AST or whatever. Then you can change the serializer with little effort.
well Jest has being doing this for a long while with snapshot testing with additional bonus of not having to provide initial value either 
New version 0.8.2 has been released
Previous version supported only argument types which implemented String.Chars protocol on the left and string heredocs on the right. 0.8.2 supports all argument types (e.g. Integer, List, Map) except not serializable (e.g. Function, PID, Reference) So now you can write
assert_value 2 + 2 == 4
assert_value %{a: true} == %{a: true}
mix test. You may get diffs because assert_value no longer converts everything to a stringASSERT_VALUE_ACCEPT_DIFFS=reformat mix test to take advantage of improved formatter[
import_deps: [:assert_value]
]
New version 0.9.1 has been released
assert_value now uses Elixir Formatter to format values. This improves formatting of big data structures. Previously assert_value formatted expected values other than strings as one line. This made code hard to read when using big data structures like long arrays and nested maps. Now we use Elixir Formatter and it formats them correctly on multiple lines.
v0.8.5
assert_value foo() == [foo: "foo", bar: "bar", baz: "baz", qux: "qux", xyz: "xyz"]
v0.9.1
assert_value foo() == [
foo: "foo",
bar: "bar",
baz: "baz",
qux: "qux",
xyz: "xyz"
]
assert_value now shows more context in diffs. Compare these two outputs:
v0.8.5
test/example_test.exs:7:"test expected" assert_value 2 + 2 failed
-
+4
v0.9.1
test/example_test.exs:7:"test example" assert_value failed
- assert_value 2 + 2
+ assert_value 2 + 2 == 4
assert_value now requires Elixir >= 1.6
[
# don't add parens around assert_value arguments
import_deps: [:assert_value],
# use this line length when updating expected value
line_length: 98 # whatever you prefer, default is 98
]
ASSERT_VALUE_ACCEPT_DIFFS=reformat mix test to take advantage of improved formatter