Doing some major cleanup in FEST-Assert 2.x

[Alex Ruiz]

Hey team,

I'm in the middle of doing some major cleanup of FEST-Assert 2.x. The change include the changes in the fluent interface I blogged about ( http://alexruiz.developerblogs.com/?p=2568 ), reverting the test organization to the way it was (removing subpackages like abstract_), removing unnecessary code, and other minor things.

This change is huge. It touches every single file in the code base and so far I have 11,000 compilation errors.

I'd like to ask you a favor, please work on branches until I finish this work. I'm documenting the changes I'm making.

Thanks,
-Alex

[Ansgar Konermann]

I doubt it makes sense to do any other work (let alone on branches or not) until the huge refactoring is done.

Who would merge the changes from a branch to a HEAD with a very very different structure?

--
You received this message because you are subscribed to the Google Groups "easytesting-dev" group.
To post to this group, send email to easytes...@googlegroups.com.
To unsubscribe from this group, send email to easytesting-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alex Ruiz]

Not "very very" different. The changes touch every file but it is not a dramatic change. The main changes relate to how we specify descriptions and comparators. I'm also removing very few assertions that provide little value and bloat the API.

Since we are talking about changes, this is what I've been thinking about what the 2.x is about:

1. Correct mistakes made in 1.x ("overrideErrorMessage" is the worst offender, my bad)
2. Make it easier for users to extend FEST (and also means we don't have to release a very rich API)
3. Provide a more compact API (in the 1.x I was willing to please users way too much and added stuff that shouldn't be there in the first place)
4. More consistent API (e.g. StringAssert has containsIgnoringCase but does not have doesNotContainIgnoringCase)

Related to #2, I think from now on we need to be extra selective with the stuff we add. We can have the policy that we only add new assertions if
1. we really think they are worth adding (kind of subjective, but we can say if at least 2 fest devs think is worth it) and
2. 5 or more users ask for a particular assertion.

WDYT?

-Alex

[Alex Ruiz]

Regarding comparators, I'm removing usage of them from assertions that deal with primitives and Strings.

-Alex

[Joel Costigliola]

Regarding comparators, I would let String comparator if some user want to make case insensitive assertions on a list of String.

2. Extending Fest should be as simple as possible, not really the case today.

3. I would remove, if not yet done, areNotAtLeast, areNotAtMost, doNotHaveAtLeast, doNotHaveAtMost and maybe areNotExactly, doNotHaveExactly.

I'm ok to have 2 fest devs to review assertion,  let's also try to give ourselves a deadline for descision (3 weeks ?) to avoid to be stuck in the case when no fest dev is answering you.

5 or more users ask for an assertion ? I don't think I have ever seen that, that's why I would say 2 with no strong Fest dev disagreement.
My general opinion is that we should be User Driven, I think Fest assertions is useful if it's useful for people (I know we don't really agree there but that is what I think).

Cheers,

Joel

[Ansgar Konermann]

Question remains:

Am 28.09.2012 15:55, schrieb Alex Ruiz:
> Who would merge the changes from a branch to a HEAD with a very very
> different structure?

s/very very/a lot of/

s/structure/content/

I'd recommend everyone to just wait until you're done.

My 2�

Ansgar

[Alex Ruiz]

Iterables and Object arrays will still use comparators (this includes a List of String). I was referring to StringAssert (sorry for the confusion) :)

I see your point about 5 users. 2 is good.

It should be user driven, but does not mean we'll please everybody. Users may come up with some esoteric assertions. We should be able to provide the means for making it easy to extend FEST.

The main complain that I have heard is that users cannot come up with their own 'assertThat' because they use static import for our Assertions.assertThat. Users think that 'Assertions.assertThat' does not read nicely. If we change it to FEST.assertThat, it reads better and users may be able to static import their own assertThat.

I was thinking that the other extension mechanism (Conditions) is OK but we don't provide some out-of-the-box conditions for mixing user conditions: And, Or, etc. Probably we should include them as well. They are just a handful. WDYT?

Cheers,
-Alex

[Alex Ruiz]

Makes sense. Thanks Ansgar.

-Alex

[Joel Costigliola]

Ok, no problem to remove comparator from StringAssert.

On Fest extension with condition : having logical operator would be great, it would allow to write basic conditions and combine them to richer ones.

On Fest extension with custom assertions classes, it should be simple to write, with user not having to know Fest internals.
I'm also working on generating custom assertion, I already have a CLI generator : give a package or a class and the tool will generate an XXXAssert class providing basic assertions for properties (see https://github.com/joel-costigliola/fest-assertion-generator/wiki).
I'm working on an eclipse plugin to do just the same from eclipse : user selects a class (let's say Jedi), and can generate JediAssert thanks to the plugin.
The user can then add whatever assertions he thinks of, this should easy for him since he already has generated assertion methods to start from, I think this would lower the barrier for user to write custom assertions (at least for me !).

[Alex Ruiz]

The assertion generator is awesome! Pretty cool stuff! Man, users are going to love it!

Cheers,

-Alex 

[Joel Costigliola]

Thanks ! :)