jsUnityRunner and jsunity
brentlintner
It has been a while since we connected last. Been very busy as I
assume you have been since we last talked.
I have been able to get a couple of hours here and there working on
polishing and enhancing jsUnityRunner.
I figured I would get a thread started and perhaps go back and forth,
see if we could collaborate in any way. :)
Anyone have any ideas? I know I'm open to anything.
Brent
Ates Goral
I've been on vacation and putting off my e-mails for a while.
I really like how the runner currently looks! I have a similar
HTML-contained runner on my branch at github, and that's using a
refactored version of jsUnity; I had started refactoring jsUnity to
turn it into just a glue for parser/runner/results modules. Let me
(re)collect the ideas I had in mind and open a roadmap discussion. My
aim was to make things easier to integrate with different flavors of
runners, separate the assertion module from the core (and perhaps
adopt the CommonJS unit testing bare minimums) and also to make
progress/result reporting more pluggable...
Ates
> --
> You received this message because you are subscribed to the Google Groups "jsUnity Development" group.
> To post to this group, send email to jsuni...@googlegroups.com.
> To unsubscribe from this group, send email to jsunity-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jsunity-dev?hl=en.
>
>
brentlintner
No worries on the time, we all try and do this in our spare time, when
we actually have it. Dan keeps telling me I should go on vacation,
perhaps I can count it as one when we head to Europe haha.
Glad you like how the runner is coming along. :-)
I love the ideas regarding CommonJS and everything else, I look
forward to hearing your ideas and any way I can help (when I can of
course!). I actually am not to knowledgeable on CommonJS it but I
checked it out briefly and I see what you mean about the Unit Testing
specs. Sweet, I'm going to have to research more on that. Also I like
really your plan to split up assertions, runners and parsing to be
more "glue like", it will make extensibility even better.
Speaking of that I also was thinking of making ruby bindings into the
html runner, probably with V8 to start, for ex. use something like
http://github.com/cowboyd/therubyracer
I might need to do some tweaking on the runner code to be completely
environment agnostic too (thinking of maybe even support some CommonJS
api's like Console). A lot of the Classes in the runner could be
common to any runner as well, if desired.
Considering I have not seen the roadmap from you etc, I'm just
throwing out ideas! But I was thinking in regards to collaboration
(along with the pluggable nature of what you plan for jsunity) do we
all think it would be acceptable to blend efforts more?
For example, I was thinking of:
1. renaming the jsUnityRunner repo to "jsunity_runner" or
"jsunity_runner_html" on github for consistency to yours
2. blend in the features from your html runner into jsUnityRunner? For
example maybe a new Class module that exposes an API for getting test
data from some runner. I was thinking this because then the xml
generator you created could be plugged into that, or even that be a
module in jsunity's runner that other runners can use or even
interface to.
3. submodule the repos into /runners on jsunity, or alternatively have
"jsunity_runner" be a separate repo for any pluggable jsunity runner
and submodule that in as /runners into jsunity (again open to any
ideas :) )
4. create a "jsunity_runner_rb" repo for ruby bindings I want to do
and figure out how best to integrate it (such as put it in
"jsunity_runner" depending if anyone likes that idea).
5. (if it is important) for pure consistency agree on stuff like
tabbing, naming conventions etc. Though why I was thinking submodules
is that we could openly collaborate on code but still maintain our
coding styles if any :).
Blah, a mouthful. Anyways, some of my thoughts. I'm open to anything.
For the meantime I am going to keep working on the runner, got a
couple of small things to finish up such as Categories and tighten
things.
Cheers,
Brent
Ates Goral
It's been a while, I apologize. Here are my belated responses inline:
On Sun, Jun 6, 2010 at 9:23 AM, brentlintner <brent....@gmail.com> wrote:
> I love the ideas regarding CommonJS and everything else, I look
> forward to hearing your ideas and any way I can help (when I can of
> course!). I actually am not to knowledgeable on CommonJS it but I
> checked it out briefly and I see what you mean about the Unit Testing
> specs. Sweet, I'm going to have to research more on that. Also I like
> really your plan to split up assertions, runners and parsing to be
> more "glue like", it will make extensibility even better.
Yeah, adding CommonJS module and test API support will be nice:
http://wiki.commonjs.org/wiki/Unit_Testing/1.0
Maybe the base assertions defined by CommonJS can be embedded and
extended assertions can be separate module(s). Or maybe all assertions
are a separate module. I don't know yet...
> Speaking of that I also was thinking of making ruby bindings into the
> html runner, probably with V8 to start, for ex. use something like
> http://github.com/cowboyd/therubyracer
>
> I might need to do some tweaking on the runner code to be completely
> environment agnostic too (thinking of maybe even support some CommonJS
> api's like Console). A lot of the Classes in the runner could be
> common to any runner as well, if desired.
Yeah, that would be cool.
> Considering I have not seen the roadmap from you etc, I'm just
> throwing out ideas! But I was thinking in regards to collaboration
> (along with the pluggable nature of what you plan for jsunity) do we
> all think it would be acceptable to blend efforts more?
I don't think I have a concrete roadmap in mind :) Just a bunch of
ideas. I'll pull my thoughts together and try to write up what I had
in mind.
> For example, I was thinking of:
>
> 1. renaming the jsUnityRunner repo to "jsunity_runner" or
> "jsunity_runner_html" on github for consistency to yours
I've seen that this has already been done :)
> 2. blend in the features from your html runner into jsUnityRunner? For
> example maybe a new Class module that exposes an API for getting test
> data from some runner. I was thinking this because then the xml
> generator you created could be plugged into that, or even that be a
> module in jsunity's runner that other runners can use or even
> interface to.
Yeah, it could be an XML conversion CommonJS module...
> 3. submodule the repos into /runners on jsunity, or alternatively have
> "jsunity_runner" be a separate repo for any pluggable jsunity runner
> and submodule that in as /runners into jsunity (again open to any
> ideas :) )
I think it would be nice to have submodules under the /runners dir so
that everything can come as a single package. Mature runners like
jsUnityRunner could be default submodules under /runners. What would
you think about moving jsUnityRunner under jsunity directly? And how
would we handle collaboration? Me pulling your changes from a fork of
jsunity?
> 4. create a "jsunity_runner_rb" repo for ruby bindings I want to do
> and figure out how best to integrate it (such as put it in
> "jsunity_runner" depending if anyone likes that idea).
I do like the idea :)
> 5. (if it is important) for pure consistency agree on stuff like
> tabbing, naming conventions etc. Though why I was thinking submodules
> is that we could openly collaborate on code but still maintain our
> coding styles if any :).
I mostly code in Crockford style: http://javascript.crockford.com/code.html
But I'm not very particular about following a single style in a
collaboration environment.
> Blah, a mouthful. Anyways, some of my thoughts. I'm open to anything.
> For the meantime I am going to keep working on the runner, got a
> couple of small things to finish up such as Categories and tighten
> things.
From the activity on your repo, I see that you've been keeping
yourself busy :) I've recently fixed a few bugs reported over at
Google Code. I was astonished by the fact that I didn't get any e-mail
notifications on the creation of those tickets. I discovered them by
pure chance :(
I currently have two development streams for jsUnity: the Google Code
"master" repo where I did the recent bug fixes, and my github clone
that I had started refactoring. I have to merge them somehow and
continue with the refactoring without breaking things (and backwards
compatibility) too much. Sigh...
Ates
brentlintner
I think I inadvertently sent my reply directly to you instead of on
the group! So I will repost, but please do delete this one if my other
one went through! :-)
..........................................................................
No worries on the time of course! Sounds like we both still are
swamped these days eh. My replies may be just as sporadic as
yours! :-)
> Yeah, adding CommonJS module and test API support will be nice:
> http://wiki.commonjs.org/wiki/Unit_Testing/1.0
> Maybe the base assertions defined by CommonJS can be embedded and
> extended assertions can be separate module(s). Or maybe all assertions
> are a separate module. I don't know yet...
on as well. jsunity_runner dev will probably not see much for the next
month or two but I do intend to update it on a lot of aspects, most
notable modularization.
> I think it would be nice to have submodules under the /runners dir so
> that everything can come as a single package. Mature runners like
> jsUnityRunner could be default submodules under /runners. What would
> you think about moving jsUnityRunner under jsunity directly? And how
> would we handle collaboration? Me pulling your changes from a fork of
> jsunity?
subfolders in runners/ for any type of runner OR submodule them in and
have them be separate repos under the jsunity account? (i.e. jsunity,
jsunity_html, jsunity_ruby or whatever kind of naming).
I am kind of on the fence with that, because it seems some runners are
more of an extension to jsunity core than something under it. I.e I
would assume the runners require jsunity rather than the other way
around, to add onto it's default console runner. Though, I would think
as long the package allows the developer to easily extract jsunity
core and/or it's runners in a modular way that would do. What do you
think?
As for collaboration I would be cool with forking jsunity and merging
in code (or forking a newly created repo for a runner if we go that
way), then doing a pull request.
> I mostly code in Crockford style: http://javascript.crockford.com/code.html
> But I'm not very particular about following a single style in a
> collaboration environment.
can as well. I'm sure we could make sure everything is a-ok in that
area.
Yeah, I have been updating some things here on there for the runner,
including some categorizing etc. Shitty about the google code
notifications! At least random chance had your back on that one
(eventually lol).
Anyways, just a brief post I wanted to get out, but I (or we) would
definitely like to merge the code bases (in whichever way). I am
guessing this will be some time in the making, with merging in those
two jsunity repos, getting jsunity_runner/jsunity into a more commonJS
format and merging them, and probably a boat more of things that will
pop up i'm sure.
Then again, really excited to collaborate. My other long term goal,
mainly because we ironically "hacked" jsunity_runner together, is to
put it fully under test. (see how that goes!)
Cheers,
brentlintner
ultimately be latched onto the jsunity namespace under something like
junity.runner? As well as overriding the base run commands?
It would be cool to be able to have a variety of runners that all
plugin through the same interface. or something like that, where
anyone could create a runner easily. :-)
brentlintner
in Ruby :D
http://github.com/mynyml/harmony