To create Unit Tests for the algorithms about ekalgorithms HOT 22 CLOSED

Hi Vittorio!

Thank you for your good ideas.
My experience with UT is limited only with OCUnit/XCTest frameworks.
If you give a starting point of how to write UT with Kiwi - I will start to learn Kiwi from your snippets & will try to help.

Best wishes.

from ekalgorithms.

It's your project, so it's up to you.
If you'd rather use XCTest, it's ok for me.
If you would like to learn some Kiwi, even better :)

Thanks

from ekalgorithms.

I see popularity of Kiwi among iOS community & also BDD paradigm is an interesting experience, I think.
So I would like to have some Kiwi skills :)
Thnx.

from ekalgorithms.

I want to suggest a couple of design notes I find useful on these days:

• I suggest using the word "Spec" and "Specs" than "Test" and "Tests" because what they should do is more likely to describe aspects of algorithms than test their stability and correctness. Stability and correctness of course are also ensured but this is done in a second order.
• I suggest the following directory structure and file organization conventions:
  • EKAlgorithms (Algorithms code)
  • EKAlgorithmsDevelopmentApp (Xcode app like current EKElgorithms/EKAlgoritms.xcodeproj is)
  • Specs

A structure of each logical part of EKAlgoritms and its files should correspond to analogous structure in Specs/ folder:

EKAlgorithms/NSArray/Sorting.{h,m} -> Specs/NSArray/Sorting.m (Spec file)

The key thing is to organize file classes properly. The result would be a very convenient project structure easy to read, spec and maintain.

A good example of such approach is my FoundationExtensions - I've built it from a ground with these things in mind.

And yes, as @vittoriom does it, I prefer Kiwi over classical OCUnit.

Let me know what you think!

from ekalgorithms.

Hi Stanislaw!

Thnx for good idea that you provide!
Undoubtedly - this idea has a common sense. It would be really nice & useful to organize file classes properly.
But unfortunately, in the near future I can not have some extra time for this issue.

Thanks again & have a nice day,
Evgeny

from ekalgorithms.

Don't forget to

[!] From now on use `EKAlgorithmsApp.xcworkspace`.

👍

from ekalgorithms.

If you like the changes proposed in #33, the next step would be something like decomposition of NSArray methods into a separate categories like NSArray/SortingAlgorithms and NSArray/SearchAlgorithms and so on.

from ekalgorithms.

Hi Stanislaw!

How to run Kiwi tests/specs?
I am trying to run - but result is an error "Library not loaded: @rpath/SenTestingKit.framework/Versions/A/SenTestingKit"

Also there is no Test option on Product pop-down menu
http://d.pr/i/nIt8

What am I doing wrong?
I am not familiar with Kiwi, sorry.

Thanks!

from ekalgorithms.

Writing you an answer...

from ekalgorithms.

There is a trick behind this setup. I wanted to document it somewhere, but forgot.

The main.m file of EKAlgorithmsSpecs contains the only following line:

SenSelfTestMain();

You should run it by switching your target to EKAlgorithmSpecs and using Run as you would go with the first target.

Technical note: this is possible only when Scheme EKAlgorithmSpecs (see "Edit scheme/EKAlgorithmSpecs/Environment variables") has the following environment variable:

DYLD_FRAMEWORK_PATH=/Applications/Xcode.app/Contents/Developer/Library/Frameworks`

from ekalgorithms.

Let me know, if it became clear to you.

from ekalgorithms.

In other words there are two Mac OS command-line applications now and you should run the second (EKAlgorithmsSpecs) to run specs!

from ekalgorithms.

Ok.
I will try this trick now.
Thnx

from ekalgorithms.

Thank !
It works now!
I am happy :)

from ekalgorithms.

I think, this issue can be closed as well. And you?

from ekalgorithms.

I don't mind
But maybe Vittorio means - "To cover all the code with UT?"
http://zsoltfabok.com/images/posts/2012-02-11-fix-all-the-failing-test-cases/fix-all-the-failing-test-cases.png
LOL

from ekalgorithms.

Hi, I'm sorry for the absence but I've been quite busy at work during these days!
Anyway yes, I meant something like: 100% code coverage with UT :)

from ekalgorithms.

I do agree that 100% code coverage is much desired, but I thought that it could be done incrementally by opening corresponding tickets/PRs that is why I suggested to close this one. We can reopen it for sure!

I do think that this work is related to a desired (I think!) decomposition of NSArray (and other classes) into smth like NSArray/SortingAlgorithms, NSArray/SearchAlgorithms and so on with writing corresponding groups of specs for each of the abstracted group of algorithms!

from ekalgorithms.

Ideally, it would be nice to have EKAlgorithms structured in way so it could be easy to read & learn algorithms like if if it was a published book with a solid structure/contents! ;)

from ekalgorithms.

Hi @stanislaw, of course when I created this ticket I just had in mind to put down some plan for covering the code base, which framework to use and so on.
I actually wanted to start covering code with Kiwi myself, but as I said before I have very little spare time at the moment to do this.
So basically yes, this ticket can be closed and more sub tickets can be created when a class or a specific part of it is going to be covered by someone :)

from ekalgorithms.

I feel we look in the same direction. Let's see, how it will go ;)

from ekalgorithms.

Guys - thanks for your activities in project!
I am going to continue develop my another yet "pet project" for the rest of the day. ;)
Thanks again for your brilliant ideas!

from ekalgorithms.