Small refactoring in searching for attributes

[Omair Majid]

* Jiri Vanek <jvanek at redhat.com> [2013-10-30 12:49]:
> On 10/30/2013 05:19 PM, Omair Majid wrote:
> >* Jiri Vanek <jvanek at redhat.com> [2013-10-30 07:14]:
> >>On 10/26/2013 03:53 PM, Omair Majid wrote:
> >>>Can you decouple the unit test from the file system? The more this unit
> >>>test does, the less useful it becomes as a 'unit' test (since the 'unit'
> >>>now becomes 3 large classes and the file system).
> >>
> >>Sorry, not in time to investiage this. So no right now ;(
> >
> >Long term, this is bad. Maybe you want to hold onto this patch until you
> >get time to sort it out completely?
> 
> please, not yet. from quick glance there is no easy solution :(
> >

Okay, but more things like this make unit tests brittle. If they are
brittle and break on other setups, they are not really helping.

> >>>>+        /* Test with attributes in manifest */ {
> >>>
> >>>When you feel tempted to write comments like this, it's an indication
> >>>that it should be a separate unit test :)
> >
> >This is still not fixed. Is there any specific reason you want to stick
> >to this style?
> 
> 
> I must admit that I do not understand what you wont me to do :(

Basically, when you have code like this:

@Test public void testSomething() {

    /* test variant 1 */

    // lots of code, part 1

    /* test variant 2 */

    // lots of code, part 2
}

It's more clear if you split it into:

@Test public void testSomethingVariant1() {
    // lots of code, part 1
}

@Test public void testSomethingVariant2() {
    // lots of code, part 2
}

That gives you smaller tests, makes it clear what the test is doing (and
what to look at in case of a failure), clarifies that variant 1 and
variant 2 are not related in terms of code dependency in the test.

Thanks,
Omair