<div dir="ltr"><div dir="ltr">On Mon, 14 Sep 2020 at 06:07, Max Lapshin <<a href="mailto:max.lapshin@gmail.com">max.lapshin@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I do not understand what fixtures are for.<br></blockquote><div><br></div><div>It's explained in <a href="http://erlang.org/doc/apps/eunit/chapter.html#Fixtures">http://erlang.org/doc/apps/eunit/chapter.html#Fixtures</a>: A "fixture" is some state that is necessary for a particular set of tests to run. EUnit's support for fixtures makes it easy to set up such state locally for a test set, and automatically tear it down again when the test set is finished, regardless of the outcome (success, failures, timeouts, etc.).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We test our flussonic in this manner:<br><br>
init_per_suite(Config) -><br>
  application:ensure_all_started(flussonic)<br>
  Config.<br>
<br>...<br>
<br>
end_per_suite(Config) -><br>
  application:stop(flussonic),<br>
  Config.<br></blockquote><div><br></div><div>This is probably because you're using Common Test, and not EUnit.</div><div><br></div><div>EUnit can be easily integrated into a module (without having to have a separate test/ folder and other "boilerplate" stuff), via -ifdef(TEST). fun_test() ..., and fixtures just make it that easy to keep all the code in the same place.</div></div></div>