[erlang-questions] Quickcheck'ing a protocol

[Andrew Berman]

Cool, thanks!

On Thu, Sep 22, 2016 at 1:28 PM James Aimonetti <james@REDACTED> wrote:

> -----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 <pierrefenoll@REDACTED>
> > 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 <josh.rubyist@REDACTED>
> 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
> >>> erlang-questions@REDACTED
> >>> http://erlang.org/mailman/listinfo/erlang-questions
> >>>
> >>>
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >>
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > 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:james@REDACTED
> 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-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160923/a5da98fd/attachment.htm>