WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
Skip to content

Conversation

@dominictarr
Copy link
Collaborator

hi

started on API docs, runSuite (which i've been using) should be correct, other functions I havn't tested yet so they may not be quite right.

although there are already some docs, I wanted to start pure API that are more rigorous that getting-started style stuff. Also, to thresh out what the interface is...

it's hard to work with an open source project when the interface is changing.
we need a consistant, flexible and stable interface.

for example, I like that onSuiteDone is called for every different way that a suite can end, but it's difficult if an argument changes it's structure in different cases, unless there is a very good reason to do so...

logging in stdio breaks it...

beginning to rewrite runFile to use some other means of communication.

moved message functions into async_testing/lib/messages.js
found a couple of problems with child,

tests that logged stuff was breaking reporting,
and you could make false positives by outputting a finish message (indicating 0 tests, which is success(!))

started working on another child process implementation, using http.

but realised that the messages must be queued, so that they arrive in order.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants