Kiwi 3.0

[supermarin]

It's been lots of changes and feedback since 2.0 is released, thanks everyone for great feedback and patches.

Due to some internal changes introduced by APL, we'll need to restructure things a bit.
For this milestone, the following things should need to be done:

• Migrate to ARC
• Make asynchronous testing the best ever (eva' eva' eva')
• Make Kiwi compatible with Xcode test runner
• AppCode compatibility
• Augment test output so it can take a format argument and be extensible
• Make the readme and documentation cleaner. We need good samples from the real world
• If possible, create a logo and a decent website

[stepanhruda]

Let's do this!

[netbe]

👍

[modocache]

👍

[lukaskubanek]

Sounds really great!

[allending]

Also, integrate with Xcode 5's latest test flow and AppCode as much as feasible :)

[supermarin]

Good point @allending, Xcode is already on the list,
but AppCode should have a dedicated checkbox :)

[orta]

Ping me if you want to talk the last checkbox once the cocoapods stuff has calmed down

[luca-bernardi]

👍

[luca-bernardi]

May I help you for something ?

[supermarin]

@orta sounds great. the logo might be on it's way soon

[supermarin]

@lukabernardi thanks, most likely there'll be places where you can contribute.

We'll have a team hangout this Friday, and after that, I expect things get moving.
Issues need to be cleaned up, and we'll break the tasks into smaller issues, so anyone can jump in and hack.

[fgarcia]

Xcode 5 support... 🙏
I love you guys!

if there is anything in Xcode 5 that makes difficult integrating Kiwi, and it is a reasonable thing to ask Apple, I would gladly send an issue by the Apple radar. It will be duplicated, but I believe every duplication counts as a vote for them.

[stepanhruda]

@fgarcia Thanks for the support. We need to figure out how Xcode 5 determines the example groups first, we should get on this pretty soon, so Kiwi supports the new Xcode as soon as it comes out.

[ketzusaka]

Xcode 5 support 👍

[fcy]

I'm wondering since Kiwi came from Rspec do you think that Kiwi will have the new expectation syntax that will be the default in Rspec?

My vote is for support the expect syntax, maybe even deprecate should.

[woahdae]

Agree with @fcy. Not just rspec (really the reference implementation for BDD libraries IMO), but also in the JS world jasmine, chai, and kinda pavlov implement an expect syntax (chai implements both).

[supermarin]

@fcy not sure that'll ever be the default RSpec's set of matchers. Kiwi is compatible (afaik) with other matchers like OCAml and Expecta. I guess Expecta is what you need.

[fcy]

@mneorr According to this article The Plan for RSpec 3 I'd say that the "old-should-syntax" might get deprecated in future versions (after 3).

[fgarcia]

So what is the deal with the new syntax for RSpec 3? Should we expect Kiwi 3 to support also the expect() based syntax? Is it an official goal for the next release?

Just noticed that in RSpec 3.0beta1 the use of should is already deprecated and must be enabled in the configuration.

There is an article explaining the reasons for that change:
http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax

That is just a minor wish, since I want to work always with the same RSpec idioms. However Kiwi is already great and really feel relieved being able to write my tests with it.

[supermarin]

It's definitely not planned to be built in, but we'll maybe support OCHamcrest and Expecta integration.

[Panajev]

OCHamcrest integration would be nice. It would also be nice to capture and compare mocks in a slightly more straightforward way than using Kiwi's spies. OCMargs and blocks based matcher blocks in OCMock make arguments matching super intuitive.

[pbernery]

Looking forward to use Kiwi 3.

What is intended for the following tasks:

• Make asynchronous testing the best ever (eva' eva' eva')
• AppCode compatibility

Is there any issue describing the needs?

A feature I would like to have: being able to set a stub for a whole describe block. Currently, stubs are reset after a it block, kind of annoying in some tests.

[modocache]

Make asynchronous testing the best ever (eva' eva' eva')

I'm also curious about what the actionable item for this milestone is.

AppCode compatibility

I think the AppCode team has put quite a bit of work into supporting Kiwi. Last I checked, it was working just as well as Xcode. Is there anything you'd still want in terms of AppCode integration, @allending?

A feature I would like to have: being able to set a stub for a whole describe block. Currently, stubs are reset after a it block, kind of annoying in some tests.

I think you can get the functional equivalent by using a beforeEach block:

describe(@"something", ^{
    // Adds the stub before each `it` block
    beforeEach(^{
        [UIApplication stub:@selector(sharedApplication)
                  andReturn:[UIApplication mock]];
    });

    it(@"does this", ^{ /* ... */ });
    it(@"does that", ^{ /* ... */ });
    it(@"does ALL THE THINGS", ^{ /* ... */ });
});

[pbernery]

I think the AppCode team has put quite a bit of work into supporting Kiwi. Last I checked, it was working just as well as Xcode. Is there anything you'd still want in terms of AppCode integration, @allending?

It works quite well indeed. What's still boring is the indentation of the first level describe block. I don't know if this more a Kiwi or an AppCode bug though.
Also, the structure pan is not showing the tests but I believe this is more of an AppCode enhancement.

I think you can get the functional equivalent by using a beforeEach block: [...]

This is exactly what I do, but this becomes annoying when you use contexts as you must create a beforeEach block for each contexts:

describe(@"something", ^{
    // Adds the stub before each `it` block
    beforeEach(^{
        [UIApplication stub:@selector(sharedApplication)
                  andReturn:[UIApplication mock]];
    });

   /* No particular context */    
   it(@"does this", ^{ /* ... */ });
   it(@"does that", ^{ /* ... */ });

    context(@"not authenticated", ^{
        beforeEach(^{
            [UIApplication stub:@selector(sharedApplication)
                      andReturn:[UIApplication mock]];
        });
        it(@"does this", ^{ /* ... */ });
        it(@"does that", ^{ /* ... */ });
    });

    context(@"authenticated", ^{
        beforeEach(^{
            [UIApplication stub:@selector(sharedApplication)
                      andReturn:[UIApplication mock]];
        });
        it(@"does this", ^{ /* ... */ });
        it(@"does that", ^{ /* ... */ });
    });
});

If I could at least do it only one time in the first beforeEach, that would be great.

[orta]

The indentation issue also happens in Specta too, I think it's an appcode/xcode issue.

[ethanmick]

Hey,

I was wondering if you had any thoughts on tweaking the async code testing? I know the Mocha framework for javascript testing does this:

  it('should do something', function(done) {
    api.post('/user')
    .end(function(err, res) {
       // test your "res" result here
      done();
    });
  });

Where you can optionally pass in a "done" method, and call that when you have finished testing. If you do not pass in "done", the test finishes as an synchronous one would.

I feel that this way is a lot more elegant than the "should eventually" method of testing. Thoughts? I love Kiwi, and I'm starting to use it for more integration testing stuff, which is pushing the boundaries of the async.

[rathahin]

👍

I would like to join the last checkbox too!

[sharplet]

@Wayfarer247:

I was wondering if you had any thoughts on tweaking the async code testing? I know the Mocha framework for javascript testing does this: ...

Where you can optionally pass in a "done" method, and call that when you have finished testing.

I feel that this way is a lot more elegant than the "should eventually" method of testing. Thoughts?

The "optional" part unfortunately couldn't be done without some kind of trampoline that allows invoking a block with a dynamic number of arguments. One possibility could be Obstruct, but unfortunately it's still experimental.

In lieu of this, it would be possible to add a new construct to explicitly allow for this kind of test, e.g.:

describe(@"Service", ^{
    let(service, ^{ return [Service new]; });

    // manual synchronisation
    it(@"can fetch a user", ^{
        asynchronously(^(KWCompletionHandler done){
            [service fetchUserWithIdentifier:@"1"
                completion:^(id user, NSError *error){
                    [[user shouldNot] beNil];
                    done();
                }];
        });
    });
});

I'm not convinced that this reads any better than the current way of writing this test:

    // automatic synchronisation via futures
    it(@"can fetch a user", ^{
        __block id fetchedUser;
        [service fetchUserWithIdentifier:@"1"
            completion:^(id user, NSError *error){
                fetchedUser = user;
            }];
        [[expectFutureValue(fetchedUser) shouldEventually] beNonNil];
    });

To me that's shorter and simpler: not as much nesting, no extraneous calls. I'm curious why you feel it's less elegant?

(Also, if the user forgot to call done(), the test would eventually have to time out—it would still work, but it may be slower than necessary. Could you instead test if done() was never called, and if so automatically fail the test? Maybe, but I'd be worried that there are legitimate cases where the test would time out and the block would never be called, so you'd have a false positive: the matcher is never registered, and this will never fail.)

I love Kiwi, and I'm starting to use it for more integration testing stuff, which is pushing the boundaries of the async.

Any chance you could share an example from your usage where you feel the async stuff is pushed to its limits?

[ethanmick]

Hmmm, you may be right. The syntax for providing a callback is not quite as simple as it would be in javascript. Perhaps if we could shorten it to something like:

(Attempted to make it prettier for three minutes).

Nope maybe not.

[woahdae]

In objective-c, we can idle our test execution thread via NSRunLoop's
-runUntilDate while the other threads keep running, and just poll for the
expected result. Javascript has no equivalent, nor could it due to it's
single-threadedness, so you must use something like the done callback
to get back into the test execution context after a async logic in a test.

Honestly, I like the simplicity of waiting & polling in objective-c. It
makes failures take longer, but is roughly the same for success & is a lot
less work to maintain.

On Sat, Apr 26, 2014 at 7:25 AM, Ethan Mick notifications@github.comwrote:

Hmmm, you may be right. The syntax for providing a callback is not quite
as simple as it would be in javascript. Perhaps if we could shorten it to
something like:

(Attempted to make it prettier for three minutes).

Nope maybe not.

—
Reply to this email directly or view it on GitHubhttps://github.com/allending/Kiwi/issues/306#issuecomment-41470060
.

[programmerdave]

Is this still being actively worked on or was it abandoned last year?

[sharplet]

Hi @programmerdave: there hasn't really been much active work happening, no. I think a lot of the team (myself included) haven't had the time.

However from what I hear there are still a lot of users out there actively using Kiwi, and hopefully it's meeting their needs.

[lolgear]

@sharplet do you think this project needs another contributor/team?

[sharplet]

@lolgear Thanks for your interest! I've just commented about this on #662.

[modocache]

Honestly, this issue holds a special place in my heart. I loved working on Kiwi 3.0!! Still, I think it's clear we don't have the resources to tackle large umbrella issues like this one. For people still interested in making the code changes to support issues herein, please send a pull request. Thanks! :)