I noticed that the necessary inconsistence, which describes in an example PropEr framework does not find a discrepancy in the RFC 4180 specification, is far from at once. I was surprised when I ran the property several times and didn’t get the error I was looking for.
$ rebar3 proper
===> Testing prop_csv:prop_roundtrip()
....................................................................................................
OK: Passed 100 test(s).
===>
1/1 properties passed
When I increased the number of tests to 1000, the framework reproduced the necessary use case.
$ rebar3 proper -n 1000
===> Testing prop_csv:prop_roundtrip()
..........................!
Failed: After 27 test(s).
[#{[40,36] => []},#{[40,36] => []}]
Shrinking .......(7 time(s))
[#{[66,65] => []},#{[66,65] => []}]
===>
0/1 properties passed, 1 failed
===> Failed test cases:
prop_csv:prop_roundtrip() -> false
PropEr can help us in it better. As we know about a possible problem we can narrow Size to 1. For this task we can add simplified generator and property-based test:
%%%%%%%%%%%%%%%%%%
%%% Properties %%%
%%%%%%%%%%%%%%%%%%
prop_roundtrip_01() ->
?FORALL(Maps,
csv_source_01(),
Maps
=:= bday_csv:decode(
bday_csv:encode(Maps))).
%%%%%%%%%%%%%%%%%%
%%% Generators %%%
%%%%%%%%%%%%%%%%%%
csv_source_01() ->
?LET(Keys, header(1), list(entry(1, Keys))).
Launching that property we get the expected error has gotten every time:
$ rebar3 proper -d apps/bday/test -p prop_roundtrip_01
===> Linking _build/default/plugins/rebar3_format to _build/test/plugins/rebar3_format
===> Linking _build/default/plugins/katana_code to _build/test/plugins/katana_code
===> Verifying dependencies...
===> Linking _build/default/plugins/covertool to _build/test/plugins/covertool
===> Compiling bday
===> Testing prop_csv:prop_roundtrip_01()
.......!
Failed: After 8 test(s).
[#{[125] => [75,85,50]},#{[125] => []},#{[125] => []}]
Shrinking ......(6 time(s))
[#{[65] => []},#{[65] => []}]
===>
0/1 properties passed, 1 failed
===> Failed test cases:
prop_csv:prop_roundtrip_01() -> false