implementing should.equal for deep equality

[yanhick]

I've started to use Buddy for a new project, it's great so far !

One of the assertions I use when doing BDD in JS is "equal" or "eql", comparing 2 objects recursively by value. Is it something which can be done ?

Thanks !

[ciscoheat]

The equality/identity issue is always tricky, especially when doing cross-platform targeting like Haxe. I'm not sure how to solve it properly since there is no standard for equality. If you have any ideas, please let me know here!

[fponticelli]

Untested has Assert.same() that does that in case you want to copy it. The cose is old but the implementation seems to hold.

Franco

On Tuesday, June 10, 2014, Andreas notifications@github.com wrote:

The equality/identity issue is always tricky, especially when doing cross-platform targeting like Haxe. I'm not sure how to solve it properly since there is no standard for equality. If you have any ideas, please let me know here!

— Reply to this email directly or view it on GitHub https://github.com/ciscoheat/buddy/issues/3#issuecomment-45613155.

[ciscoheat]

Thanks, I looked at it earlier for some ideas but not in detail. Do you know the basic equality thinking for that algorithm?

[yanhick]

There is also this approach used by haxe.unit but it is seems really hackish: http://old.haxe.org/doc/cross/unit#comparing-complex-objects

2014-06-10 16:03 GMT+02:00 Andreas notifications@github.com:

Thanks, I looked at it earlier for some ideas but not in detail. Do you know the basic equality thinking for that algorithm?

— Reply to this email directly or view it on GitHub https://github.com/ciscoheat/buddy/issues/3#issuecomment-45617116.

[ciscoheat]

Btw @yanhick , did you update to the latest version (0.3.1)? I changed should.equal() to should.be() to improve the semantics, since both equality and identity are tested depending on type. I also added tests for exceptions.

[fponticelli]

My implementation takes care of all the the Haxe basic types and uses recursion optionally. It first checks for matching types and behave accordingly. For instances of custom classes it iterates on all the field and value pairs. The implementation is in sameAs function.

On Tue, Jun 10, 2014 at 9:09 AM, Andreas notifications@github.com wrote:

Btw @yanhick https://github.com/yanhick , did you update to the latest version (0.3.1)? I changed should.equal() to should.be() to improve the semantics, since both equality and identity are tested depending on type. I also added tests for exceptions.

— Reply to this email directly or view it on GitHub https://github.com/ciscoheat/buddy/issues/3#issuecomment-45626471.

[yanhick]

Nice implementation @fponticelli ! I didn't think it would be this complex.

@ciscoheat : yes I saw the change to "equal", I still have to update my test, I only have a couple for now.

[ciscoheat]

The complexity scares me a bit, it's like implementing an "equatable" interface for the major part of the language, with platform differences to consider as well. Could be a bit of work to maintain...

[yanhick]

Yes I understand. Buddy is interesting for me as I personnaly prefer BDD over TDD. Why not focus buddy on BDD ("describe", "it", "should") but use another lib internally for assertions, like utest.Assert ?

It's just an idea, I perfectly understand that you'd like your own implementation.

2014-06-10 17:34 GMT+02:00 Andreas notifications@github.com:

The complexity scares me a bit, it's like implementing an "equatable" interface for the major part of the language, with platform differences to consider as well. Could be a bit of work to maintain...

— Reply to this email directly or view it on GitHub https://github.com/ciscoheat/buddy/issues/3#issuecomment-45630145.

[ciscoheat]

That's a good idea! I'd like to do it at least for utest since it's very popular. @fponticelli is there anything else to it than setting Assert.results = something; and then it's possible to use the static methods?

[yanhick]

Any update on this @fponticelli ? I can help with integrating utest assertion if needed

[jasononeil]

+1 for this.

Looking forward to using the library, and I've always been pretty happy with utest's assert class :)

[ciscoheat]

I'll take a look at that now, I'm thinking that adding -D utest could be a way of enabling it. Or perhaps more metadata on the main class, since you have to add implements Buddy on it anyway. Any suggestions?

[jasononeil]

I think -D utest is fine - it would be implied by -lib utest and is probably easier for you then trying to read metadata to know whether to use it or not.

[ciscoheat]

Actually, in AutoIncluder I'm using Context.getClassPath() to detect promhx. It could be used to detect if utest is included too, and then use it automatically. There's no reason to include it with -lib utest unless you want to use it, right?

[ciscoheat]

Now I see what you mean @jasononeil, I didn't know using -lib something also defined "something" as a preprocessor directive.

[ciscoheat]

@yanhick @jasononeil You should be able to use utest now from version 0.7.0! Just call Assert methods in any spec, no need to do anything else. Please test if you have some time. :)

[jasononeil]

:+1: works for me!

One positive of this is it will allow you to begin transitioning a unit testing suite over and slowly make it more BDD style. Nice :)

[yanhick]

Cool ! I'll try during the week.

One thing I didn't get is, will I use utest's assert class directly or will it be wrapped in a "should" ?

[ciscoheat]

It works as a replacement for should, so just use Assert.something() directly.