Welcome to my Programming Blog...

I am currently working on a couple of projects: An original game called "Implosion" which I am porting from Flash to the iPad, and a remake of Q*bert in Python (pygame), as part of the class I am teaching. Please feel free to use the "Labels" (at right) to follow a specific project or theme. If you are one of my Python students, I recommend that you check out the Python thread.

Saturday, October 16, 2010

#VTM_iPhone notes on STAssertTrue

Here are my notes on Graham Lee' unit testing presentation. Note: coming into this, I have heard of unit testing and have a general idea of what it means, but I have never seen it done. I presume it means to do an automated process of running a method with different data sets and checking that the answer is what you wanted each time. Probably, it includes boundary cases, but I don't know.

Software engineering goals: make money (sometimes)... By making something that the user wants. - meets their requirements, without being too expensive.

Testing isn't about finding bugs - it's about validating that your code does what it should., finding bugs is a secondary effect.

The earlier a bug is introduced, the more it costs if you find it late. Unit testing helps with the design and build aspects reducing errors.

Undirected unit testing - checking the minutiae of the program, the opposite side from external testing by somebody who doesn't know the program I.e., the user.

test driven development:
*black-box thinking for the developer.
*YAGNI you ain't gonna need it. Only write the code you need.
*Avoid regression bugs. Keep the tests around, so later code doesn't break earlier code without your knowledge.
*assists accurate planning

Find bugs before....
...your customers do.
Zune didn't know about leap year. Ah, they're incredibly rare.
TDD != [bullet silverColor]
you can't assume the developer understood the problem...or that the requirements didn't change, and it doesn't guarantee successful integration
Takes time to write tests, and you actually run them.

How TDD works: RED - GREEN - REFACTOR
What do I test? Anything within reason - time, environmental conditions (ie DBs, filesystem, network - not repeatable)
Evaluate risk - known buggy code, heavily used code, tricky problems
When do I test? At any change, plus before release.


Testable code: short classes with short methods, each with obvious effects, few & predictable side effects, with helper data passed in - not discovered, low "cyclomatic complexity" - don't need to test thousands of combinations.

This means the end of a @interface GodView:UIViewController


OCUnit and XCode3 or XCode4
GHUnit ... Better than OCUnit? (Does it run on the iPod, itself?-HH)
plug of kaleidoscope app?

Fakes and mocks? Fake is dummy input data, and mock is dummy local data, I think.... - HH

Recommends "refactoring: improving the design of existing code", "test-driven development"(Kent beck), "test-driven development: a practical guide", "xUnit test Patterns", et al

Iamleeg at the usual sites, twitter, etc.


Note: I know more than I did, but I still don't know enough that I am ready to go out and start unit testing. A lot of theory here, but I probably needed a more practical demonstration.

- Posted using BlogPress from my iPad

2 comments:

  1. After my blog was posted, Graham Lee got in touch with me and sent me a link to a real-world example on his blog:
    http://tinyurl.com/2wtchfe

    ReplyDelete
  2. Glad you picked up on the blog post with the example. I was just coming here to link to it :). Great notes, thanks for publishing them. I've made the slides available at: http://www.slideshare.net/iamleeg/unit-testing-for-cocoa-developers

    BTW regarding fakes and mocks, while there is a distinction (fakes are things that let you control a method's input, mocks let you see the method's output) I tend to lump them together as "things that let you see what's happening in a method".

    ReplyDelete