Thursday, May 5, 2011

Easiest Example That Could Possibly Click

I'm a big fan of unit test cases. Mapped 1:1 with the objects they test (as opposed to "let's say it tests unit of functionality"). But I also write a lot of class side example methods, for the sake of prototyping, feedback, and ad hoc testing. Especially as you get into UI development, this becomes very helpful. It's hard (not impossible) to test how the pixels end up looking and interacting with unit tests.

The classic pattern you see in Smalltalk is

exampleMethod
  "self exampleMethod"

  self
    example;
    code;
    goes;
    here


Then what you do, is navigate to the method, highlight the comment and do it. If you're doing it a lot, it gets tedious to select the comment and then execute it.

So I made a simple little package called RBEasyExampleMethods, put in the repository. It makes it so you can just double click on a method in the browser, and if it looks like an example, it runs it. It looks like an example when it's

  • a class side method

  • unary (no arguments)

  • starts with 'example' OR lives in a category that starts with 'example'


It should work with VisualWorks versions from quite a ways back. Enjoy!

2 comments:

  1. Hello!

    Nice little addition, but could you consider extend it a little bit to also support management-like code? I mean things like:

    SomeClass class>>purgeSomething
    "Optional explanation what it does."

    "self purgeSomething."
    ...


    The rules would be:
    * It must be a class side method with no arguments.
    * One of its comments has the form "self methodSelector.".


    Just my 2cents,

    Ladislav Lenart

    ReplyDelete
  2. If you use tests then you can combine the 'Mark I eyeball' test with assertions, either right away or as you work on the task. I think there are many cases where Mark I eyeball and self assert: can cooperate to good effect.

    Of course, the Mark I eyeball takes time, and a test will normally close the window it opens, perahps too fast. Is this where you see the two maybe conflicting rather than cooperating?

    I would rather see this new utility of yours as a modification to SUnit (actually to SUnitToo, I presume, for SUnit to steal later) than an alternative. Is there a case for a button, parallel to the step into button, that, instead of halting at the start of a test, halts at the end, before it begins tearDown? Or an pragma that SUnitToo recognises and handles appropriately?

    ReplyDelete