Sure, how you test is a big part of making it useful.
It really depends on what you are testing or how complicated it is, but rather than simply testing whether properties exist as a type, you might test functionality in use. For instance, with a stream, the stream tests would actually test all the basic operation. Construct a stream by whatever means you want (different types of streams), then run the tests against the implementation. On Friday, 6 July 2012 13:07:15 UTC-5, José F. Romaniello wrote: > > I have seen a lot of tests in node packages like these here: > > https://github.com/flatiron/winston/blob/master/test/winston-test.js#L24 > > assert.isObject, assert.isFunction, etc > > I see this as a common practice and i think it is a way to define an > interface close to what a compiler in an static language will do. I have a > lot of respect for the ones that write this kind of tests but I dont see a > lot of value on this. > > The only value I can see is that if you broke your "interface" a tests > will fail with "xxx.doY expected to be a function". I write tests for the > behavior only... so if I broke my interface I will see a javascript default > error "OBJECT CALL AS A FUNCTION" or "undefined is not a function". > > > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
