-
Notifications
You must be signed in to change notification settings - Fork 512
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kiwi 3.0 #306
Comments
👍 |
1 similar comment
👍 |
Sounds really great! |
Also, integrate with Xcode 5's latest test flow and AppCode as much as feasible :) |
Good point @allending, Xcode is already on the list, |
Ping me if you want to talk the last checkbox once the cocoapods stuff has calmed down |
👍 |
May I help you for something ? |
@orta sounds great. the logo might be on it's way soon |
@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. |
Xcode 5 support... 🙏 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. |
@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. |
Xcode 5 support 👍 |
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. |
@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. |
@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). |
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: 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. |
It's definitely not planned to be built in, but we'll maybe support OCHamcrest and Expecta integration. |
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. |
Looking forward to use Kiwi 3. What is intended for the following tasks:
Is there any issue describing the needs? A feature I would like to have: being able to set a stub for a whole |
I'm also curious about what the actionable item for this milestone is.
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?
I think you can get the functional equivalent by using a 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", ^{ /* ... */ });
}); |
It works quite well indeed. What's still boring is the indentation of the first level
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. |
The indentation issue also happens in Specta too, I think it's an appcode/xcode issue. |
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:
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. |
👍 I would like to join the last checkbox too! |
@Wayfarer247:
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
Any chance you could share an example from your usage where you feel the async stuff is pushed to its limits? |
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. |
In objective-c, we can idle our test execution thread via NSRunLoop's Honestly, I like the simplicity of waiting & polling in objective-c. It On Sat, Apr 26, 2014 at 7:25 AM, Ethan Mick notifications@github.comwrote:
|
Is this still being actively worked on or was it abandoned last year? |
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. |
@sharplet do you think this project needs another contributor/team? |
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! :) |
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:
The text was updated successfully, but these errors were encountered: