Skip to content
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

Receive and beEvaluated matchers, mocks #183

Open
trimmurrti opened this issue Jun 7, 2016 · 7 comments
Open

Receive and beEvaluated matchers, mocks #183

trimmurrti opened this issue Jun 7, 2016 · 7 comments

Comments

@trimmurrti
Copy link

Recently, Kiwi anounced, that they are dropping the support and future development, so I'm thinking about transitioning to Expecta. One thing, that holds me back, is that there are some matchers and features, which I use all the time and which are absent in expecta. Namely, receive matcher, mocks, evaluation matcher for blocks (see my pull request here: kiwi-bdd/Kiwi#673 ).

I can implement them in expecta, but I was wondering, if it would be in vein with expecta philosophy to implement such a functionality? So, could please someone shed some light on the issue?

@trimmurrti trimmurrti changed the title Receive and beEvaluated matchers Receive and beEvaluated matchers, mocks Jun 7, 2016
@orta
Copy link
Member

orta commented Jun 7, 2016

Expect is built to be expanded on, you could happily create these matchers and release them as a library that exists outside of Expecta - we've got quite a lot of these now. Given the complexity of that PR, I'd probably say that's a better place for it.

Though I'd wait on the Kiwi responses in kiwi-bdd/Kiwi#662 too, it does look like a lot of work.

@trimmurrti
Copy link
Author

trimmurrti commented Jun 7, 2016

Wasn't as much for Kiwi, as it had a foundation to build on. It would be an awful lot of work for Specta/Expecta on the other hand. That's why I'm asking about the philosophy, as that would require a lot of changes to the base test classes to implement properly). That's the exact reason why simple matcher creation won't do in that case. Only fork, only hardcore, sadly. As Specta/Expecta is positioned as light weight, I was wondering, if it would actually be any good for the framework.

As for Kiwi, in the light of the Kiwi discussion you took part in, I doubt they will review the pull, as it's would surely be classified as a large commit (base classes had to be changed as well) and Kiwi maintainers told, that they are not going to accept such pulls in the upstream prior to the final release.

@orta
Copy link
Member

orta commented Jun 7, 2016

I'm not adverse to it, but my philosophy on Specta/Expecta is a part of what inspired the Kiwi philosophy.

So long as it's well tested, easy to maintain and if questions come up in the future I can ping you about it, then it's OK by me.

@trimmurrti
Copy link
Author

Got your point. Thank you. I will review the Specta/Expecta code a bit more to figure out, what should go where and how to best tackle the issue at hands. From the discussion thread you sent, did I get it right, that there are no new features implemented, but in case of bugs in the core lib in the future, it will still be supported?

If I take on the issue (as this is a lot of work and I need to analyze, how I would approach the task and how I would transition my companies internal projects to Specta/Expecta), I would of course be available after the implementation it in case something is not right. I can't promise though, that I will be able to fix it immediately leaving all my duties behind, but I would surely spend my weekends (and weekdays, if available) to make it work properly.

As for the maintenance ease, could you please explain what do you mean? Do you mean documentation, comments and tests of the functionality, along with code readability, proper naming and stuff? Or something else entirely?

@orta
Copy link
Member

orta commented Jun 8, 2016

As for the maintenance ease, could you please explain what do you mean?

Just the usual PR things, I've received PRs with all the variables in Chinese, and not really been able to say I can accept it as I can't maintain and understand it if I need to.

From the discussion thread you sent, did I get it right, that there are no new features implemented, but in case of bugs in the core lib in the future, it will still be supported?

Yep, I'm not planning on building anything new, but I'm keeping it ticking, I have tens of projects relying on Specta/Expecta, it's not going anywhere.

I can't promise though, that I will be able to fix it immediately leaving all my duties ...

Don't worry, I'm not after a contract, just that I can @trimmurrti you occasionally if it looks like something related to those changes

@trimmurrti
Copy link
Author

Well, as I previously mentioned, I don't mind fixing and helping out on the weekends as well.

Got your point.

Still, after reviewing your OCMock specta repo, I'm thinking, if modifications to the base repo are even worth it. Because, after examining it Specta/Expecta/OCMock expecta repo more closely, I see, that there are ways of actually implementing everything I need in a less intrusive way. In that case, the base repo will stay clean of my experiments, while mocking behaviors would stay external.

The only real downside of a less intrusive way, is that you would have to do that in a dealloc method (the same way you did). But I can bear with this ::--))

Still, thank you very much for your prompt and informative responses. In case you need spare hands with Specta/Expecta issues/problems, don't hesitate to contact me.

@orta
Copy link
Member

orta commented Jun 10, 2016

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants