Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That sounds like a complicated approach at it. Here's an example of some NodeUnit tests that involve communications with a Redis-based message queue:

https://github.com/bergie/noflo/blob/master/test/MQ_SendMess...

More BDD-ish version of something similar:

https://github.com/nemein/kckupmq/blob/master/test/001_kckup...



Does that test you link actually talk to a live Redis-based message queue that must exist for the test to run?

If so, while that's a nice test there's also a need to be able to fully control the event loop so you can test arbitrary event orders, some of which you may not be able to synthesize (or not easily, or not reliably) but may be able to occur in the real world. Testing event loop code sucks hard enough when you can fake events perfectly correctly, take that away and it sucks even worse.


>there's also a need to be able to fully control the event loop so you can test arbitrary event orders

Hmm, something doesn't sound right there. I'm not really sure why you'd want to "fully control the event loop" for testing, but if you did you can install a callback on every tick: http://nodejs.org/api/process.html#process_process_nexttick_...

If you want to test arbitrary inbound event sequences, you'll need to run at least two processes. You could run two node processes, one generating events for the other. This would probably give you a better test environment then hacking the event loop, too.


"I'm not really sure why you'd want to "fully control the event loop" for testing,"

Because while I'm actually one of the first to tell you that not everything needs to be a unit test and I tend to prefer integration tests over unit tests if given a choice, I will also say that unit tests still have their place, and the way you unit test an event-driven program is to feed the events you specify to an event loop and ensure that the proper actions taken, using whatever is necessary to ensure proper independence.

It's nice to be able to do integration tests, it is not nice to have to do integration tests.

You know, this may explain a great deal of the gap between my opinion of event-based programming and the conventional Node opinion. Testing event-based code isn't necessarily that hard (testing is never really easy in a language where you're always in the local IO monad equivalent, though cracking it up into events does make things challenging, especially if you try to take advantage of closures in your handlers, which unfortunately is advantageous in other ways but hurts testability hard) but it doesn't help that the frameworks never seem to ship with the testing support I just specified and I'm always having to bash it together myself, which tends to show a certain... disconnect in expectations between me and the authors.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: