Prev: Some Javascript newbie questions
Next: Workaround for IE6 select width cut off options' width
From: David Mark on 7 Jan 2010 14:36
On Jan 7, 2:15 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> David Mark wrote:
> > Garrett Smith wrote:
> >> David Mark wrote:
> >>> On Jan 7, 3:46 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> >>>> On Jan 7, 1:24 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>
> >>>>> David Mark wrote:
> >>>>>> On Jan 7, 12:20 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> >>>>>>> David Mark wrote:
> >>>>>>>> On Jan 6, 5:12 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> >>>>>>>>> David Mark wrote:
> >>>>>>>>>> On Jan 6, 6:36 am, Matt Sach <matts...(a)gmail.com> wrote:
> >>>>>>>>>>> On Jan 5, 10:57 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> >>>>> [...]
> >>>>>> Like this:-
> >>>>>>http://www.cinsoft.net/attributes.html
> >>>>> That is a combination of an article and a series of assertions in the
> >>>>> source.
> >>>>> A test case is code only.
> >>>>> A separate article can refer to the test case.
> >>>> You are splitting hairs.  Sure it could be broken up into two pages
> >>>> (and likely will be in the near future).
>
> >> You can do whatever you like, but I'm telling you that when I see that
> >> test, it is hard to follow.
>
> > What are you talking about?  The tests couldn't be more straightforward.
>
> There is no test function, just a long series of assertions.

Yes, I follow you there. I plan to consolidate the common logic.

>
> | if (typeof assertEquals == 'function' && typeof prop == 'function') {
> |
> | var el, elTest, elProgress, count, set, skips, failures, errors,
> |
> | domSkips, domFailures, hostAttrTotals, hostPropTotals,
> | wrapperAttrTotals,
> |
> | wrapperPropTotals, doc = window.document, html = doc.documentElement;
> |
> |
> | var startTime = new Date().getTime();
> | elTest = doc.getElementById('test1');
> | elProgress = doc.getElementById('progress1')
> | count = failures = skips = errors = 0;
> | hostAttrTotals = { failures: 0, skips:0, errors:0 };
> | set = 1;
> |
> | el = elTest.getElementsByTagName('a')[0];
> | docWrite('<h3>Anchor<\/h3>');
> |
> | assertEquals(el.getAttribute('tabindex'), null,
> | 'Anchor tab index missing');
> | el.setAttribute('tabindex', '0');
> | assertEquals(el.getAttribute('tabindex'), '0',
> | 'Anchor tab index added');
> |
> | if (assertNotEquals(el.getAttribute('href'), null,
> | 'Anchor reference present')) {
> |   assertEquals(el.getAttribute('href'), 'images/cinsoft.gif',
> | 'Anchor reference unresolved');} else {
>
> |
> |   skipTest('Anchor reference unresolved');
>
> }
>
> It goes on for several hundred lines.

There are several hundred tests. Putting white space between the
assertions would go a long way towards making it clearer, but I plan
to make it so that you don't have to view the test code to see exactly
what the tests are doing. You'll see what I mean.

>
> You have there an assertion in an if statement. Tests should never
> affect other tests. Well, you don't actually have *tests*, just a mile
> of assertions and if-else statements.

I'm not interested in semantics. And you are mistaken about the if-
else. That is used to _skip_ a test that would have no way of
determining a valid result.

>
> The code would be easier to follow if you break it up into test functions..
>
> var uriTestCase = {
>    testAHref : function(){
>
>    },
>    testLinkHref : function() {
>
>    }
>
>    // etc.
>
> };

I know. That page is just something I threw together. It is not
indicative of what I will use for unit testing on cinsoft.net (or for
My Library).

>
> MyTestRunner.addTest( uriTestCase );
>
> When the test runner runs, it reports something like:-
>
> testLinkHref: PASS
>
> or
>
> testLinkHref: FAIL: expected "foo" (string), found 12 (number).
>
> or
>
> testLinkHref: FAIL. ERROR. Stack trace: (line 12 object expected).

Yes, of course. I have all of that (just not on that page). :)

>
> That way you can run all the tests and see what fails, and then focus on
> what fails and see how it failed, then go straight to the function and
> see exactly what the test function is doing.

Yes.

>
> A two line function is great for that, because that way anybody can look
> at your two-liner and see what is going on straight away.
>
> It might be hard to see the value in that for someone who has never
> tried doing that.

No, it is hard for you to see what I am doing as I haven't published
it yet. I never meant to imply that the attributes test page was
indicative of what I would be using for unit testing (just that it
contained simple tests). I've written unit testers and have also
debugged Dojo's. No worries. ;)

>
> [...]
>
>
>
> >> Regardless, the aspects of YUI Test that I outlined are valuable design
> >> decisions.  I can and do point those out to Nicholas (though a good
> >> number remain unfixed).
>
> > Why am I not surprised?
>
> Surprised at what? The fact t hat YUI Test author knows principles of
> unit testing? Or surprised that things haven't been fixed?

That they haven't been fixed. Apathy is clearly the "driving force'
behind YUI (and things like it). :)

>
> A lot of my older tests are complicated, though, and you'll notice that
> as I've gotten more experience,  the test have gotten very short.

I hadn't looked. But I imagine they look a lot like the million other
unit tests I've encountered.

>
> Here is an example of a good test I wrote the other day:-
>
> | testNamespaceOther : function() {
> |   APE.namespace("other");
> |   YAHOO.util.Assert.isObject(window.other);
> | }

Yep. I think the confusion was that I was trying to see something new
in what you were telling me. I know what "real" unit tests look like
(as opposed to that one-off attribute test page). ;)

>
> Two lines of code and one assertion. I already made enough suggestions
> for how to use that approach for testing DOM stuff. Maybe even too much.

What and to whom?

>
> Now if I look at tests I wrote last year, oh no. Twenty line unit test
> functions. Blah. What was I thinking? Very hard to follow.

What were you thinking?

>
>
>
> >> Separate test cases with simple test functions, setUp, tearDown, go a
> >> long way toward making the test code easy to read and failures easy to
> >> spot.
>
> > They would only make my test code _more_ complicated.  So I don't see
> > the point.
>
> I tried to show you what could be improved but you don't see it.  You
> have a long series of assertions and not contained test functions.

You misunderstood what I said about that page. It's clearly not a re-
usable test suite. I was only indicating that the tests were simple.

>
> You probably won't see much value in testing until you get some
> experience doing it.

You really misunderstood. :) Every project I've ever worked on has
used a similar test utility. Most recently Dojo (as I mentioned),
which I had to wade through at the lowest levels to get working with
my re-designed loader.

>
> I learned unit testing from writing JUnit and TestNG tests. I also had
> pain using that JSUnit, which is a good example of what a js test
> framework should not be.

Yes, the first one rings a bell. They are all about the same to me.

>
> I still recommend at least download and try it out. I would like to have
> Nicholas fix his bugs and I would like the Timing manager added (would
> greatly improve efficiency and avoid BB9k crashes), and I would like YUI
> Test to not have 200 LOC methods that are so painful to "step over"
> (debugger), and it should have stack traces like my hacked version does.

My hacked version of Dojo's tester is likely similar (stack traces
were there, but I had to fix something with them IIRC).

>
> All shortcomings aside, there are good aspects of YUI Test that you can
> learn about unit testing (so you don't have to use JUnit or TestNG).

I don't have to use any of them. Such utilities are trivial to write
(and I already have one ready to go).
From: Erwin Moller on 19 Jan 2010 03:26
David Mark schreef:
> I've decided to release My Library under some sort of free license.
> Haven't thought about free licenses in a long time (decades), so I am
> open to ideas.
>
> Anything to prevent the exponential growth of JS futility like this;-
>
> http://github.com/jrburke/blade
>
> I don't think that thing even warrants a review and there are dozens
> more like it popping up. Enough is enough. :)


Hi David,

No license advice (as far as I can judge good advice has been given
already): just a thumbs up.
Thumbs up for the fact you will release it under a friendly license.
Another thumbs up for the initiative to create/develop something better.

I think it is a good move you decided to take My Library to another level.

In the worst case nobody can say to you anymore: "Don't criticise JS lib
XYZ. If you can do it better show us, or shut it up!".

In the best case you put some serious competition in the market.

Good luck!
I'll keep an eye on the cinsoft website.

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
From: David Mark on 20 Jan 2010 09:38
On Jan 19, 3:26 am, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...(a)spamyourself.com> wrote:
> David Mark schreef:
>
> > I've decided to release My Library under some sort of free license.
> > Haven't thought about free licenses in a long time (decades), so I am
> > open to ideas.
>
> > Anything to prevent the exponential growth of JS futility like this;-
>
> >http://github.com/jrburke/blade
>
> > I don't think that thing even warrants a review and there are dozens
> > more like it popping up. Enough is enough. :)
>
> Hi David,
>
> No license advice (as far as I can judge good advice has been given
> already): just a thumbs up.

Thanks!

> Thumbs up for the fact you will release it under a friendly license.
> Another thumbs up for the initiative to create/develop something better.

Thanks again!

>
> I think it is a good move you decided to take My Library to another level.

In more ways than one. ;)

>
> In the worst case nobody can say to you anymore: "Don't criticise JS lib
> XYZ. If you can do it better show us, or shut it up!".

Well, that was the "argument" years back when I first lit into one of
the "majors" (jQuery). That platform collapsed in early 2008 with the
posting of the library. Then it sat for years while everyone who
ostensibly wanted to work on a better project made excuses and
continued to work on complete wastes like jQuery. The argument
changed to "UR just jealous coz nobody uses your library". And nobody
got the name. To this day, I hear people say "oh, how egotistical".

So, after re-writing most of Dojo (still waiting to see if the
original authors can figure it all out) and seeing more bad JS
libraries coming out every day, I figured I'd take a week or two and
polish mine off.

Other complaints I often heard over the years were lack of good
documentation (which is now slightly improved, but still lacking),
examples (tons of those in the test page and more in the
documentation), support (see My discussion forum) and unit testing
(took an hour to do the basic stub that is up there now, another two
to implement async tests for Ajax, audio, etc.) So, I can't imagine
why anyone would wait around for John Resig and his friends to learn
browser scripting. Seems like a very hard (and expensive) way to
go. ;)

>
> In the best case you put some serious competition in the market.

What competition? Seriously. Every time I look at a so-called
contender, it turns out to be a giant collection of dated browser
observations by beginning developers (who all consider themselves
geniuses at JS) that _nobody_ is ever going to go back and rewrite (my
recent Dojo effort was a huge exception to this rule). They are just
like old television models that are in millions of homes, but nobody
would buy another one.

>
> Good luck!
> I'll keep an eye on the cinsoft website.
>

That's where I am going to consolidate all of this information about
other libraries, how Cinsoft can help (we are the foremost experts on
JS libraries and frameworks, real and imagined). For the moment,
watch the My Library site (and forum).
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Some Javascript newbie questions
Next: Workaround for IE6 select width cut off options' width