[erlang-questions] Quickcheck'ing a protocol

James Aimonetti <>
Thu Sep 22 22:28:39 CEST 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


You should check out Thomas Arts' talk from this past Erlang Factory:

https://www.youtube.com/watch?v=iW2J7Of8jsE

The ideas should be generally applicable.

Andrew Berman writes:

> Hey Pierre,
>
> 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?
>
> Thanks!
>
> On Wed, Sep 21, 2016 at 10:58 PM Pierre Fenoll <>
> wrote:
>
>> Have you tried using PropEr / Quickcheck statem?
>> http://proper.softlab.ntua.gr/Tutorials/PropEr_testing_of_finite_state_machines.html
>> PropEr is free & open source & I use it to quickcheck RESTfull APIs.
>>
>>
>>
>> Cheers,
>> --
>> Pierre Fenoll
>>
>> On 22 September 2016 at 05:45, Josh Adams <> wrote:
>>
>>> So I've been frustrated lately by the fact that Slack's IRC gateway isn't
>>> RFC 2812 compliant (https://github.com/bitwalker/exirc/issues/51)
>>>
>>> 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).
>>>
>>> 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?
>>>
>>> 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.
>>>
>>> Thoughts?  Pipe dream?  "Silly child, see A, B, and C for the many people
>>> who are already doing this?"
>>>
>>> --
>>> Josh Adams
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> 
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions


- --
James Aimonetti

Lead Systems Architect
"If Dialyzer don't care, I don't care"
2600HzPDX | http://2600hz.com
sip:
tel:415.886.7905
irc:mc_ @ freenode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX5D73AAoJENTKa+JPXCVg8SwH/jTe/EhqLBQc1b82rptahsuy
SL2dwQjzq6kxfzJquVE05t4yjjhI3GKaHoaeGkPMNF4Wq4Y9ZdWVOrIfyE1fHuxg
EltLgUq6OAjQeCYkQXNOTtcWzt6AJ8ZpKK9z9U7hydJL9NAs1IF6v2D/NjbvJ02H
OAlRLZzhqcN1nm+/yOPPqs9zBac5SR3YHK3bo8A5vlx5M+8jrI3SV6fe5cBXTbIF
CzVKmrlD3EZlGEYaDN1ssFDShv42CZJk4+2bvQnsJDJ4YRe7WqoDOJIhgcg92Tuo
ntiYR8nlMY+qzDWYjOZnpVNNUN5oudLUjmhCuLU5vGwkLB74Y+2YBwxbC7gabec=
=KvP6
-----END PGP SIGNATURE-----


More information about the erlang-questions mailing list