To create Unit Tests for the algorithms

[vittoriom]

I'm quite a fan of unit testing (not necessarily TDD), and while refactoring methods of EKSearchStuff, EKSortStuff and EKArrayStuff I found myself in the position of having to check the console (for the output of the main file) to see if I broke something or not. I would like to create a unit tests suite (if you don't mind I would use Kiwi framework) to make it easier in the future to refactor things and also for new people to add new algorithms. Of course I won't be able to write the whole suite by myself, so I will need some help. What do you think?

[EvgenyKarkan]

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.

[vittoriom]

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

[EvgenyKarkan]

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.

[stanislaw]

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!

[EvgenyKarkan]

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

[stanislaw]

Don't forget to

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

:+1:

[stanislaw]

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.

[EvgenyKarkan]

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!

[stanislaw]

Writing you an answer...

[stanislaw]

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`

[stanislaw]

Let me know, if it became clear to you.

[stanislaw]

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

[EvgenyKarkan]

Ok. I will try this trick now. Thnx

[EvgenyKarkan]

Thank ! It works now! I am happy :)

[stanislaw]

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

[EvgenyKarkan]

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

[vittoriom]

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 :)

[stanislaw]

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!

[stanislaw]

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! ;)

[vittoriom]

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 :)

[stanislaw]

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

[EvgenyKarkan]

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!