EvgenyKarkan/EKAlgorithms

To create Unit Tests for the algorithms

vittoriom opened this issue · 22 comments

vittoriom commented

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 commented

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 commented

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 commented

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 commented

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 commented

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 commented

Don't forget to

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

👍

stanislaw commented

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 commented

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 commented

Writing you an answer...

stanislaw commented

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 commented

Let me know, if it became clear to you.

stanislaw commented

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

EvgenyKarkan commented

Ok.
I will try this trick now.
Thnx

EvgenyKarkan commented

Thank !
It works now!
I am happy :)

stanislaw commented

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

vittoriom commented

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 commented

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 commented

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 commented

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 commented

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

EvgenyKarkan commented

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!