I am looking forward to being excited about it! As soon as I get my
mind around proper and the rest.

On Tue, Mar 22, 2011 at 3:02 PM, Torben Hoffmann
<torben.leh...@gmail.com> wrote:
> Gentlemen,
>
> Between the two of you you have provided the perfect combination of
> explanations that will allow me to speak to and from your input and straight
> into property based testing Nirvana!
>
> I am stuck with day job tasks tonight, so I will get back in the saddle
> tomorrow and I am so looking forward to completing this.
>
> A heads up: I talked to Kostis who is on the PropEr team and they are coming
> out with something this week that allows for stateful testing - I know it
> does not mean much to you, but that feature is so golden that you wouldn't
> believe it!
> When we are done with erlware_commons we can find a piece of code that is
> best tested with this approach and then we document how that is done.
>
> Cheers,
> Torben
>
> On Tue, Mar 22, 2011 at 17:43, Martin Logan <martinjlo...@gmail.com> wrote:
>>
>> That last sentence should be:
>>
>> As the code is tried in further exploratory testing and in production
>> new input parameter sets for which the given function does not meet
>> the stated contract are discovered and added to the test case once a
>> fix has been put into place.
>>
>> On Tue, Mar 22, 2011 at 11:41 AM, Martin Logan <martinjlo...@gmail.com>
>> wrote:
>> > For me unit testing is about contracts. I think about the same things
>> > I think about when I write statements like {ok, Resp} =
>> > Mod:Func(Args). Unit testing and writing specs are very close for me.
>> > Hypothetically speaking lets say a function should return return {ok,
>> > string()} | {error, term()} for all given input parameters then my
>> > unit tests should be able to show that for a representative set of
>> > input parameters that those contracts are honored. The art comes in
>> > thinking about what that set is.
>> >
>> > The trap in writing all your own tests can often be that we think
>> > about the set in terms of what we coded for and not what may indeed be
>> > asked of our function. As the code is tried in further exploratory
>> > testing and in production new input parameter sets that don't meet the
>> > contract are discovered and added to the test case once a fix has been
>> > put into place.
>> >
>> > Cheers,
>> > Martin
>> >
>> > On Tue, Mar 22, 2011 at 8:04 AM, Torben Hoffmann
>> > <torben.leh...@gmail.com> wrote:
>> >> Eric,
>> >>
>> >> And if you could send me some words about the thinking that you put
>> >> into the
>> >> creation of those unit tests it would make it so much evident where the
>> >> two
>> >> approaches are similar and where they differ.
>> >>
>> >> I can fabulate on the reasoning, but I'd rather have the thought
>> >> process
>> >> described by some one who has actually done a lot of unit tests.
>> >>
>> >> TO ALL: **** Anyone can chip in and describe the way they think when
>> >> doing
>> >> unit testing, it does not have to be Eric.***
>> >>
>> >> It is not going to be used to point fingers, but to make it easy to
>> >> understand what you have to do differently when changing to property
>> >> based
>> >> testing.
>> >>
>> >> I can promise you this: if you jump on the property based testing wagon
>> >> you
>> >> will experience fun with testing like never before.
>> >> A new and better you will emerge on the other side.
>> >>
>> >> Cheers,
>> >> Torben aka The ErlangPriest
>> >>
>> >>
>> >> On Mon, Mar 21, 2011 at 23:59, Eric Merritt <ericbmerr...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Torben,
>> >>>
>> >>>  I will put together an eunit test for add in ec_dictionary by
>> >>> tomorrow. And then we can move from there.
>> >>>
>> >>> Eric
>> >>>
>> >>> On Mon, Mar 21, 2011 at 5:57 PM, Torben Hoffmann
>> >>> <torben.leh...@gmail.com> wrote:
>> >>> > Hi again,
>> >>> >
>> >>> > Manolis helped me debug a very stupid thing on my side, so now we
>> >>> > have a
>> >>> > running property based test suite for ec_dictionary that tests
>> >>> > ec_gb_trees
>> >>> > for now.
>> >>> >
>> >>> > Action plan - not necessarily in strict order, but close and some
>> >>> > items
>> >>> > can
>> >>> > be repeated as desired...
>> >>> >
>> >>> > receive a description of how to do a unit test of
>> >>> > ec_dictionary:add/2.
>> >>> > write a description of how a property based test of
>> >>> > ec_dictionary:add/2
>> >>> > looks like and how it differs from unit testing.
>> >>> > receive suggestions for new properties from the group - I will help
>> >>> > turn
>> >>> > them into correct properties.
>> >>> > make it possible to test different ec_dictionary implementations.
>> >>> > figure out (with the help of Manolis) how to use the Auto-ADT
>> >>> > functionality.
>> >>> > enhance the description with how to use Auto-ADT.
>> >>> > support others in applying PropEr on selected modules in the Erlware
>> >>> > suite.
>> >>> > be happy.
>> >>> >
>> >>> > Cheers,
>> >>> > Torben
>> >>> >
>> >>> >
>> >>> > On Mon, Mar 21, 2011 at 20:57, Torben Hoffmann
>> >>> > <torben.leh...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >>
>> >>> >> On Mon, Mar 21, 2011 at 16:11, Eric Merritt
>> >>> >> <ericbmerr...@gmail.com>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> I went a bit nuts over the weekend and pulled Robert Virding's
>> >>> >>> rbtree
>> >>> >>> implementation and changed it to be a native implementation of our
>> >>> >>> dictionary. I wanted something a bit more complex then the assoc
>> >>> >>> list
>> >>> >>> stuff.
>> >>> >>
>> >>> >> Walking on fire... but that is also where the fun is!!
>> >>> >>
>> >>> >>>
>> >>> >>> Most of us don't have much experience with quick check, proper or
>> >>> >>> property based testing. We are using this opportunity to go
>> >>> >>> through
>> >>> >>> and figure it all out so we can start using it. Is there any
>> >>> >>> chance
>> >>> >>> you could go through this first test and give some specific
>> >>> >>> documentation of what is going on in each case? Then I will try to
>> >>> >>> add
>> >>> >>> some tests to it myself and see how it goes.
>> >>> >>
>> >>> >> I have given a bit of thought to this too, and I think that if I
>> >>> >> get
>> >>> >> get a
>> >>> >> good explanation of how one of you guys would test the
>> >>> >> ec_dictionary:add/2
>> >>> >> function then I could explain what the differences are when doing
>> >>> >> it
>> >>> >> with
>> >>> >> property based testing. I think that would be a good context for
>> >>> >> understanding how the two approaches differ and how property based
>> >>> >> testing
>> >>> >> provides more value.
>> >>> >>
>> >>> >> Does this make sense?
>> >>> >>
>> >>> >>>
>> >>> >>> More inline:
>> >>> >>>
>> >>> >>> On Sun, Mar 20, 2011 at 10:53:04PM +0100, Torben Hoffmann wrote:
>> >>> >>> >    Hi,
>> >>> >>> >
>> >>> >>> >    I have added more properties to test/ec_dictionary_proper -
>> >>> >>> >
>> >>> >>> >
>> >>> >>> >
>> >>> >>> >  [1]https://github.com/lehoff/erlware_commons/blob/master/test/ec_dictionary_proper.erl
>> >>> >>> >
>> >>> >>> >    I would encourage you all to go a and look and them and send
>> >>> >>> > me
>> >>> >>> >    suggestions to new thing to be tested for a dictionary.
>> >>> >>> >
>> >>> >>> >    I have run into a problem where it seems that PropEr is able
>> >>> >>> > to
>> >>> >>> > create a
>> >>> >>> >    dictionary based on gb_trees where the same key is present
>> >>> >>> > more
>> >>> >>> > than
>> >>> >>> > once.
>> >>> >>> >    That is bad(tm).
>> >>> >>> >    Unfortunately I have not been able to work well enough with
>> >>> >>> > PropEr
>> >>> >>> > to get
>> >>> >>> >    a sequence of operations out that shows how it actually
>> >>> >>> > created
>> >>> >>> > such
>> >>> >>> > an
>> >>> >>> >    instance of gb_trees, but when I do I will explain the
>> >>> >>> > finding in
>> >>> >>> > details.
>> >>> >>>
>> >>> >>> Our 'add' maps to the gb_trees enter function. According to the
>> >>> >>> docs
>> >>> >>> it should insert if the key doesn't exist or update if the key
>> >>> >>> exists. Could this be a key equality problem. That is =:= vs ==, I
>> >>> >>> suspect not since you are using integers for the keys but it
>> >>> >>> doesn't
>> >>> >>> hurt to ask the obvious questions.
>> >>> >>
>> >>> >> Hmmm, that is actually something that I did not pay attention to.
>> >>> >> It
>> >>> >> won't
>> >>> >> do any harm with the integers I am using now, but for others it
>> >>> >> could
>> >>> >> be an
>> >>> >> issue, so I will think about how this is tested the best.
>> >>> >>
>> >>> >> Cheers,
>> >>> >> Torben
>> >>> >>
>> >>> >>>
>> >>> >>> >    The failing property is called prop_to_list_mathes_get() and
>> >>> >>> > it
>> >>> >>> > tries to
>> >>> >>> >    compare the output of ec_dictionary:to_list to the output of
>> >>> >>> > using
>> >>> >>> >    ec_dictionary:get/2 on all the keys in the to_list output.
>> >>> >>> >    They are not the same in some cases due to the gb_trees thing
>> >>> >>> > above.
>> >>> >>> >
>> >>> >>> >    Most likely I am doing something extremely stupid, but it
>> >>> >>> > could
>> >>> >>> > be
>> >>> >>> > fun if
>> >>> >>> >    there was a subtle bug in gb_trees... or maybe the right word
>> >>> >>> > is
>> >>> >>> > scary...
>> >>> >>> >
>> >>> >>> >    Cheers,
>> >>> >>> >    Torben
>> >>> >>> >    --
>> >>> >>> >    [2]http://www.linkedin.com/in/torbenhoffmann
>> >>> >>> >
>> >>> >>> > References
>> >>> >>> >
>> >>> >>> >    Visible links
>> >>> >>> >    1.
>> >>> >>> >
>> >>> >>> >
>> >>> >>> > https://github.com/lehoff/erlware_commons/blob/master/test/ec_dictionary_proper.erl
>> >>> >>> >    2. http://www.linkedin.com/in/torbenhoffmann
>> >>> >>>
>> >>> >>> --
>> >>> >>> Eric Merritt
>> >>> >>> Erlang & OTP in Action (Manning) http://manning.com/logan
>> >>> >>> http://twitter.com/ericbmerritt
>> >>> >>> http://erlware.org
>> >>> >>>
>> >>> >>> --
>> >>> >>> You received this message because you are subscribed to the Google
>> >>> >>> Groups
>> >>> >>> "erlware-dev" group.
>> >>> >>> To post to this group, send email to erlware-dev@googlegroups.com.
>> >>> >>> To unsubscribe from this group, send email to
>> >>> >>> erlware-dev+unsubscr...@googlegroups.com.
>> >>> >>> For more options, visit this group at
>> >>> >>> http://groups.google.com/group/erlware-dev?hl=en.
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> http://www.linkedin.com/in/torbenhoffmann
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > http://www.linkedin.com/in/torbenhoffmann
>> >>> >
>> >>
>> >>
>> >>
>> >> --
>> >> http://www.linkedin.com/in/torbenhoffmann
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "erlware-dev" group.
>> >> To post to this group, send email to erlware-dev@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> erlware-dev+unsubscr...@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/erlware-dev?hl=en.
>> >>
>> >
>> >
>> >
>> > --
>> > Martin Logan
>> > Erlang & OTP in Action (Manning) http://manning.com/logan
>> > http://twitter.com/martinjlogan
>> > http://erlware.org
>> >
>>
>>
>>
>> --
>> Martin Logan
>> Erlang & OTP in Action (Manning) http://manning.com/logan
>> http://twitter.com/martinjlogan
>> http://erlware.org
>
>
>
> --
> http://www.linkedin.com/in/torbenhoffmann
>

-- 
You received this message because you are subscribed to the Google Groups 
"erlware-dev" group.
To post to this group, send email to erlware-dev@googlegroups.com.
To unsubscribe from this group, send email to 
erlware-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/erlware-dev?hl=en.

Reply via email to