<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div style="direction: inherit;">There are a bunch of papers / thesis on this topic. </div><div style="direction: inherit;">I recommend the statem doc link I posted earlier. </div><div style="direction: inherit;">There's a talk from Quviq at latest SF Erlang Factory: <a href="https://m.youtube.com/watch?v=iW2J7Of8jsE">https://m.youtube.com/watch?v=iW2J7Of8jsE</a></div><div style="direction: inherit;">Note that Quviq provides a paid CI service. My bet is a service that quickchecks a project's APIs would be worth good money. </div><div style="direction: inherit;">Here's a simple example of a PropEr statem: <a href="https://bitbucket.org/fenollp/kzp/src/7e6518dd33e1461cdecba22bc9e767aeb372d4d9/test/prop__user_auth.erl?at=master&fileviewer=file-view-default">https://bitbucket.org/fenollp/kzp/src/7e6518dd33e1461cdecba22bc9e767aeb372d4d9/test/prop__user_auth.erl?at=master&fileviewer=file-view-default</a></div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Please share your troubles / findings :)</div><div><br>On 22 Sep 2016, at 19:53, Andrew Berman <<a href="mailto:rexxe98@gmail.com">rexxe98@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hey Pierre,<div><br></div><div>How do you QuickCheck RESTful APIs? I'm a noobie with QuickCheck and using it with RESTful APIs would be really useful to me. Do you have any sample code or is there a tutorial anywhere?</div><div><br></div><div>Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 21, 2016 at 10:58 PM Pierre Fenoll <<a href="mailto:pierrefenoll@gmail.com">pierrefenoll@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Have you tried using PropEr / Quickcheck statem? <a href="http://proper.softlab.ntua.gr/Tutorials/PropEr_testing_of_finite_state_machines.html" target="_blank">http://proper.softlab.ntua.gr/Tutorials/PropEr_testing_of_finite_state_machines.html</a><div>PropEr is free & open source & I use it to quickcheck RESTfull APIs.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div><br></div><div>Cheers,</div></div></div></div></div></div><div class="gmail_extra"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div>-- </div><div>Pierre Fenoll</div></div></div></div></div></div><div class="gmail_extra">
<br><div class="gmail_quote">On 22 September 2016 at 05:45, Josh Adams <span dir="ltr"><<a href="mailto:josh.rubyist@gmail.com" target="_blank">josh.rubyist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So I've been frustrated lately by the fact that Slack's IRC gateway isn't RFC 2812 compliant (<a href="https://github.com/bitwalker/exirc/issues/51" target="_blank">https://github.com/bitwalker/exirc/issues/51</a>)<div><br></div><div>In dealing with this I wondered why the crap they needed an engineer to go through the spec as a result of their server's response to figure out that this was an issue (they've added it to their bug tracker, so I have some amount of faith it might get fixed eventually - for now I'll paper over the issue in the client which reduces the stress on them to actually fix it though).</div><div><br></div><div>Should RFCs / protocols of this nature just come with something like a quickcheck model for their spec? Is anyone aware of prior art around this sort of thing aside from Quvic/Volvo that I could draw from if I wanted to fiddle in this arena?</div><div><br></div><div>I'd think that the ideal situation involves an open source quickcheck implementation to test a given protocol implementation against at least some of the RFC, and a means to run the tests against potential servers/clients, with badges potentially showing the percentage of the test that passes. This would allow economics to drive spec implementers towards correctness, which would save countless engineer-hours spent figuring out why the damn clients can't talk to the damn servers for a given spec.</div><div><br></div><div>Thoughts? Pipe dream? "Silly child, see A, B, and C for the many people who are already doing this?"<span><font color="#888888"><br clear="all"><div><br></div>-- <br><div>Josh Adams<br></div>
</font></span></div><span><font color="#888888"><img src="http://t.sidekickopen65.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v4dY_WW8r56Rz643_PgW2B8dD01pctGFW5PXYkH1k1H6H0?si=4827575526621184&pi=db5006c4-7640-4826-df8e-17e939e11c75" style="display:none!important" height="1" width="1"></font></span></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>
</div></blockquote></body></html>