rustkas

Property-Based Testing with PropEr, Erlang, and Elixir: the location of the function under test (page 411)

In the 5th Question of the third chapter, it was proposed to create a function, as well as a testing property to test its work. In your answer on page 411, author suggested to write in a function in a properties file. Interesting. Why did you decide to write the function under test here? May be the module solutions in the source code folder src would be better place for it? It is very interesting to know the course of your thoughts on this issue.

Source code of the module in the src folder would be like this:

-module(solutions).

-export([word_count/1]).

word_count(String) ->
% ...

Property based test source code in the test folder would be like this:

-module(prop_solutions).

-include_lib("proper/include/proper.hrl").

%%%%%%%%%%%%%%%%%%
%%% Properties %%%
%%%%%%%%%%%%%%%%%%
prop_word_count() ->
    ?FORALL(String, (non_empty(string())),
            (word_count(String) =:= alt_word_count(String))).
% ...

I also noticed that Fred placed the call to the function under test on the left in the comparison expression. Why? He already explained this to me earlier.

Full project.

2 comments

#question /book-property-based-testing-with-proper-erlang-and-elixir

2 740 2

2021-06-17 15:34:44 UTC

Marked As Solved

ferd

Author of Property-Based Testing with PropEr, LYSE, & Erlang in Anger

In normal production code you’d expect to ship it would be correct to put all implementation code on src/ and keep tests in test/.

However, since this is a book, I put them the way they are so that I could have one test file and one solutions file, and keep them separate from the project code for chapters when I was working on them. It reduces some amount of scattering and made it easier for me to just focus on the exercises, while also simplifying the annotations internal to source files when selecting subsets that get to be included in the book.

A reader downloading the code archive would also be able to look at the project without getting its code interspersed with exercises, which they legitimately my want to skip over, which is something I wanted to avoid as a potential confusion here.

One of the things not seen by the reader (by design), for example, is that I wanted all code to be testable for the book, including failing cases. So there are chapters there are 3 or 4 copies of a module existing. In chapter 3 it’s possible I had src/thinking.erl (final version), src/thinking.erl.a (first iteration shown), src/thinking.erl.b (second iteration), and so on.

This is something I could do so that if PropEr got upgrades while writing the book, I could go back in and re-generate the snippets for result sets in a way that wouldn’t require me to re-write everything every single time, while still leaving an artifact on disk that the PragProg editing system can bring into the page.

What I’m saying here is that the choice of where to put the code in this case is one of code organization related to the book and its authoring process, and specifically here, keeping exercises and solutions separate from the chapter’s project both for my sake, but also for the sake of readers who might want to look ahead in the code bundle that ships with the book without caring for the exercises.

The code has a distinct purpose from shipping software, and its organization may reflect that.

A note on the last comment there: there is far less thought going into which order to put functions in the assertions than you are implying here. My other response mentions a possible approach I could suggest in general, but at the time of writing it the book, I didn’t ask myself that question at all, and I don’t think it really matters ultimately due to being in comparison. I think I can suggest swapping the order from what I typically write, but I would never call it out in a code review, if that helps qualify the strength of how I feel about this.

Post #2

Also Liked

rustkas

Fred, thanks a lot for the detailed answer. Your invaluable experience and the order of thought is very interesting, as it helps to better understand your plan and priorities.

The tool (rebar3), thanks to which it is easy and pleasant to learn Erlang, helps a lot.

Post #3