JBossDeveloper

"kukeltje" wrote:

But before I can assert something, I need to see it first... Are there really two tokens? Yes... Ok, assert.

I disagree. You can assert ANYTHING, e.g. assert that you expect one token. The test fails because there are more tokens. Assert that the token is in a certain state: it succeeds or fails and the real value is always printed.... I initially did it as you mention, but starting with assertions is way easier and more understandable for others if something goes wrong.

Ok.

Now, I fully appriciate the help you guys are giving me. Again many thanks for that. And I even appriciate the promotion of unittests, although you are talking to an already converted believer. But I do think it is a bit overdone to try to tell me how I should work my way to a unittest, as long as -when I'm done- there is a nice unittest with assertions.

So when I'm busy learning something (like JBPM here) I prefer prints. Simple, straight forward and it outputs the info exactly at the right time, over and over again, without me having to think in advance about what should be there. Token classes? Node classes? Iterator? I'm learning what should be there, prints are telling me this, and then I can replace the prints with assert and continue to the next part. Step by step.

I most definitely use debuggers, but for when I need to trace the execution, and they often involve tiredsome manual "step-in", "execute-out", "run-to" and other program flow management, which I do not like. Especially if certain pieces of code have to be navigated multiple times. Plus, how do you think I should have illustrated my problem we discussed in the thread? Make a movieclip of the debugger screen?

So, again, I'm very grateful for the help, and I'm a great proponent for unittests, but let's keep the how-to-get-there to each's personal taste. I use intermediate prints, you guys use asserts. Great. At least we all write unittests.