Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Events: Use EventEmitter model for logging system #882

Closed
wants to merge 6 commits into from

Conversation

leobalter
Copy link
Member

Closes #422
Replaces #644

This is a rebased branch from @JamesMGreene's work on #644 to finish the EventEmitter.


[WIP]

@leobalter
Copy link
Member Author

I still need to figure out a way to run both logs and events tests on node.

@leobalter
Copy link
Member Author

I never involved myself too much on the js-reporters or the Event Emitter before.

Now that I'm trying to finish this pull request I have some thoughts and concerns:

From js-reporters perspective, we have one non-compliant event: the assert event. It's a great feature, but it sounds like a missing piece there.

js-reporters is a good project but in my own PoV, it's a great test report adapter to connect many test frameworks to many other test tools, like Karma, Grunt, Browserstack, etc. On the other side, I wouldn't like to use it for actual reporters (like html, console, tap, etc).

This PR does not adapt QUnit with the event details for js-reporters, and they are not consistent yet: qunitjs/js-reporters#30.

It looks like js-reporters does not support ES3 and even PhantomJS (using Function.prototype.bind without a fallback). QUnit still supports ES3 environments. We can't just ship it along with QUnit 1.x without breaking anything else.

For an actual reporter and adapter, we could also solve it easily if we have an tap output. Everything else could parse a tap log, as every test framework should do it just fine as well. Maybe if we have a method to call on a QUnit.done or an 'runEnd' event, we could return a string containing the whole tap log to be used on any adapter. That does not avoid implementing a real time tap reporter.


With that said, my suggestion is to land this PR as it is and work on tap reporter on the top of it (without using js-reporters). The events details should be addressed only after qunitjs/js-reporters#30 is done.

@leobalter leobalter force-pushed the JamesMGreene-EventEmitter branch from 360cd50 to a1f766a Compare October 25, 2015 19:31
@leobalter
Copy link
Member Author

a1f766a solves the problem with running both events and logs on the node tests. (the commit reference will chance within the next rebase/squash).

throw new Error( "Emitting QUnit events requires an event type" );
}

callbacks = listeners[ type ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May wanna call .slice() here at the end to ensure a consistent event run.

@leobalter leobalter force-pushed the JamesMGreene-EventEmitter branch 2 times, most recently from f8e28ea to 1c65763 Compare October 27, 2015 02:56
@leobalter
Copy link
Member Author

@Krinkle 1c65763 calls slice() and bf2e02c does not cache .length

@jzaefferer
Copy link
Member

@leobalter I appreciate that you spent some time looking into js-reporters! This looks like a great opportunity to improve the js-reporters spec, instead of partially ignoring it.

Since there a quite a few details to discuss, could we do a Skype/Hangouts call sometime this week? Hopefully @fcarstens can join as well.

@leobalter
Copy link
Member Author

Since there a quite a few details to discuss, could we do a Skype/Hangouts call sometime this week?

I'm in!

@Krinkle
Copy link
Member

Krinkle commented Dec 9, 2015

Can we separate the addition of EventEmitter from the test-on-node refactoring? Either land that first, or keep it out for now. I'd like to review and land this pull request this month.

Also, I'd like to land it without changing existing code or tests that use events. Only add a few tests for the EventEmitter.

In a later patch, when we deprecate and introduce warnings for the old code, we can update the existing tests. That way I can have greater confidence in it not breaking any existing code and keeps the patch more minimal.

@leobalter
Copy link
Member Author

Sure. I still need to work on the event details for this PR as well.

@Krinkle Krinkle changed the title Events: QUnit logging system uses EventEmitter Events: Use EventEmitter model for logging system Dec 9, 2015
@leobalter leobalter force-pushed the JamesMGreene-EventEmitter branch from 1c65763 to f421ec3 Compare February 1, 2016 14:13
@leobalter
Copy link
Member Author

This is rebased and the test-on-node refactoring got its own PR (more rebases on the way).

I still need to finish the work on the events, which will consume some time but it's better to have new events with legacy details.

"moduleStart", "moduleDone" ];
var dictionary = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jzaefferer
Copy link
Member

Since #981 was closed, bringing this up here again:

Since it looks like the new event emitter API won't make it into 2.0.0, can we release the new API somewhere in a 2.x release, while keeping the existing callbacks intact? We could then remove the old callbacks in 3.0.

New events with old event data (or both old + new data) seems like a bad idea, so I think it would be better to add the new API with new data, then eventually remove the old API....

@flore77
Copy link
Contributor

flore77 commented Jul 21, 2016

Hey,

I would like to continue this and to integrate the js-reporters standard into QUnit. How should I start? Should I rebase this onto master ? Thanks.

@jzaefferer
Copy link
Member

@trentmwillis since you're working on the conversion to ES6 modules, rebasing this now probably makes no sense, right? Any idea how long you'll be working on that?

@trentmwillis
Copy link
Member

@jzaefferer I'm hoping to have a PR ready within the next couple of days (mainly restructuring/organizing things right now). I don't necessarily think it'd be a bad idea to rebase this as the ES6 modules changes will be minimally invasive into the actual logic (mainly just adding import/export statements).

@jzaefferer
Copy link
Member

Gotcha, thanks.

@flore77 Let's try an initial rebase soon. If its non-trivial to resolve, we can still discuss when and how to make it work.

@trentmwillis
Copy link
Member

Closing this in favor of #1026.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

8 participants