What's a good license for My Library?

[Garrett Smith]

[...]

I think not.

Those could all be improved by automation. Significantly

Please don't make me click through to every example and don't make
complicated test cases (like an functional/example page that has every
usage of the property/method).

No clue what that means.

By functional test, here, I am referring to here is a static demo page,
like any of the Hixie or Juriy tests.

Another sort of functional test is use-case functionality. Selenium is
useful for that.

Clicking each example is tiresome and doesn't give a comprehensive view
of what works and what fails.

A functional test that tries to test everything about one specific
property is worse because it is not focused on one thing.

Unit tests are the well-suited for testing browser features and dom
features because each aspect can be tested.

insertBefore suite might contain: testReturnsNode, testRefNodeNull,
testHeirarchyRequestErr, testWrongDocumentErr, testNoModificationErr,
testNotFoundErr.

A unit test page can do those things and separate out the test cases to
test functions, where each function tests one specific thing, using
maybe 4-8 lines of code for each test function.

Or that.

Specifications should provide guidance for the outcome of assertions and
also can help outline an API.

For example, any of the DOM APIs could be tested, ECMA specs can be
tested. Such tests would be valuable to me. I believe they could
potentially contribute usefull to the w3c APIs. I doubt that anyone in
the w3c would be able to see it. I might have had better luck if I had
shown them actual test cases. That takes a bit of time to set up. You
can see my input to that here:

http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0013.html

I'm no sure what the status is; I can't follow up because I was banned
from the list.

I don't need to write one. I have what I need for now.

That's what Hixie said. I still think he's missing something valuable in
that. He doesn't (or didn't) see value in it. His acid tests, to me, are
not valuable tools that I can refer to to see what works where, etc. His
functional tests require a click through to each one are not even
indexed that well. Having to click through does not provide a
comprehensive view of what fails and what passes because you have to
click through to each one, and in each browser, to see those results.

What is valuable for me, is to see the appendChild method, see where it
fails, and see an example of it.

You are getting way ahead of me.

For example, say you ahve an XHR adapter. The adapter makes a call to
the server, and when the response comes, you need to verify that response.

A test case wants to test the success of a response.

To test that, the test case gets a connection. Opens, sends, and then
*waits* for the response. The `success` callback fires asynchronously;
it cannot be tested until the xhr is complete. The problem is, we don't
know when that will happen.

What YUI Test provides is a `wait` method. `wait` takes two arguments:
callback, and timeout millis. So what you can do is to wait for a while.

The assertions that verify the message of the ajax call are performed in
the `wait` callback.

test case:-
this.wait(function(){
Assert.areSame("a", xhr.responseText);
}, 4000);

I would like a `waitForCondition` method, so I could, say:-

this.waitForCondition(function(){
Assert.areSame("a", xhr.responseText);
}, condition);

function condition(){
xhr.complete == true;
}

I don't really like that order, but it is consistent with the `wait`
approach.

Also, I don't like how most x unit frameworks have expected result
first. TestNG (Java) is switched, which makes sense, but inconsistent.

Whatever YUI is doing with their stuff is irrelevant.

If you try the test runner, you might get a feel for the API and about
testing. You'll find what you don't like and maybe you might find things
that are valuable in it. It is a lot better than JS Unit.

The problems in the design of the YUI Test are solvable; it's not like
he painted himself into a corner.

 

[David Mark]

David Mark wrote:
As for the "goals":-
    * Mobile is more important than Internet Explorer

[...]

I think not.

Those could all be improved by automation. Significantly
Please don't make me click through to every example and don't make
complicated test cases (like an functional/example page that has every
usage of the property/method).

No clue what that means.  

By functional test, here,  I am referring to here is a static demo page,
like any of the Hixie or Juriy tests.

Another sort of functional test is use-case functionality. Selenium is
useful for that.

Clicking each example is tiresome and doesn't give a comprehensive view
of what works and what fails.

A functional test that tries to test everything about one specific
property is worse because it is not focused on one thing.

Unit tests are the well-suited for testing browser features and dom
features because each aspect can be tested.

insertBefore suite might contain: testReturnsNode, testRefNodeNull,
testHeirarchyRequestErr, testWrongDocumentErr, testNoModificationErr,
testNotFoundErr.

A unit test page can do those things and separate out the test cases to
test functions, where each function tests one specific thing, using
maybe 4-8 lines of code for each test function.

Like this:-

http://www.cinsoft.net/attributes.html

Specifications should provide guidance for the outcome of assertions and
also can help outline an API.
Okay.


For example, any of the DOM APIs could be tested, ECMA specs can be
tested. Such tests would be valuable to me. I believe they could
potentially contribute usefull to the w3c APIs. I doubt that anyone in
the w3c would be able to see it. I might have had better luck if I had
shown them actual test cases. That takes a bit of time to set up. You
can see my input to that here:

http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0013.html

I'm no sure what the status is; I can't follow up because I was banned
from the list.

You can't even read it? That's insane, but GG does the same thing.
Of course, you just create a new account.

That's what Hixie said. I still think he's missing something valuable in
that. He doesn't (or didn't) see value in it. His acid tests, to me, are
not valuable tools that I can refer to to see what works where, etc. His
functional tests require a click through to each one are not even
indexed that well. Having to click through does not provide a
comprehensive view of what fails and what passes because you have to
click through to each one, and in each browser, to see those results.

What is valuable for me, is to see the appendChild method, see where it
fails, and see an example of it.

Yes, I can't imagine having to click to see each result.

For example, say you ahve an XHR adapter. The adapter makes a call to
the server, and when the response comes, you need to verify that response..
Right.


A test case wants to test the success of a response.

To test that, the test case gets a connection. Opens, sends, and then
*waits* for the response. The `success` callback fires asynchronously;
it cannot be tested until the xhr is complete. The problem is, we don't
know when that will happen.

Well, I think that's simple enough.

What YUI Test provides is a `wait` method. `wait` takes two arguments:
callback, and timeout millis. So what you can do is to wait for a while.

I get it.

The assertions that verify the message of the ajax call are performed in
the `wait` callback.

test case:-
  this.wait(function(){
    Assert.areSame("a", xhr.responseText);
  }, 4000);

I would like a `waitForCondition` method, so I could, say:-

  this.waitForCondition(function(){
    Assert.areSame("a", xhr.responseText);
  }, condition);

  function condition(){
    xhr.complete == true;
  }

I don't really like that order, but it is consistent with the `wait`
approach.

Also, I don't like how most x unit frameworks have expected result
first. TestNG (Java) is switched, which makes sense, but inconsistent.



If you try the test runner, you might get a feel for the API and about
testing. You'll find what you don't like and maybe you might find things
that are valuable in it. It is a lot better than JS Unit.

I've been all through Dojo's, which I imagine is similar.

The problems in the design of the YUI Test are solvable; it's not like
he painted himself into a corner.

Who?

 

[Garrett Smith]

[...]

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 might consider breaking up the assertions into groups of tests, or
test cases. One for the wrapper, one for properties, and one for
attributes. I would probably consider putting each test case into a
separate document, so that each document is simpler.

A test case has a setup, a teardown, and one or more named test methods.
Each test function tests one specific thing and has one assertion per test.

Tests (test functions) do not affect other tests.

An HTML template can be used to prevent tests from affecting other
tests. The way it works is a setUp/tearDown "sandbox" resets the
innerHTML of the template div. This allow for each test do to anything
in there without affecting other tests. A template might not work for
your specific "attributes" test, but can be useful for most things.

<div id="template">
<a id="testLink">a</a>
</div>

var template = document.getElementById("template"),
templateHTML = template.innerHTML,
testLink;

var myTestCase = {
setUp : function(){
testLink= document.getElementById("testLink");
},

tearDown : function(){
template.innerHTML = templateHTML;
},

testGetHref : function(){
Assert.areSame(null, testLink.getAttribute("href"));
}
};

Resetting the innerHTML (in tearDown) means that test1 can do anything
inside that template without affecting test2. Tests should never affect
each other.

[...]

Who?

Nicholas wrote that.

 

[David Mark]

David Mark wrote:
David Mark wrote:
On Jan 5, 10:57 pm, David Mark <[email protected]> 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 might consider breaking up the assertions into groups of tests, or
test cases. One for the wrapper, one for properties, and one for
attributes. I would probably consider putting each test case into a
separate document, so that each document is simpler.

A test case has a setup, a teardown, and one or more named test methods.
Each test function tests one specific thing and has one assertion per test.

Tests  (test functions) do not affect other tests.

An HTML template can be used to prevent tests from affecting other
tests. The way it works is a setUp/tearDown "sandbox" resets the
innerHTML of the template div. This allow for each test do to anything
in there without affecting other tests. A template might not work for
your specific "attributes" test, but can be useful for most things.

<div id="template">
   <a id="testLink">a</a>
</div>

var template = document.getElementById("template"),
     templateHTML = template.innerHTML,
     testLink;

var myTestCase = {
   setUp : function(){
     testLink= document.getElementById("testLink");
   },

   tearDown : function(){
     template.innerHTML = templateHTML;
   },

   testGetHref : function(){
     Assert.areSame(null, testLink.getAttribute("href"));
   }

};

Resetting the innerHTML (in tearDown) means that test1 can do anything
inside that template without affecting test2. Tests should never affect
each other.

There's not a chance in hell I would mix up innerHTML machinations in
the tests like this. I would (and did) use a distinct "template" for
each set of tests. No need to try to put Hunpty Dumpty back together
each time.

[...]

Who?

Nicholas wrote that.

Zakas? I wondered who that was. I recently read some opinion by him
(on browser sniffing IIRC) that was so outrageously ignorant and
confused as to insult my intelligence. Oh, I remember. It was posted
less than two weeks ago:-

http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-browser-detection/

Cross-browser scripting is a _very_ small town. This ridiculous
article was offered up as a "good example" (for me!):-

http://groups.google.com/group/comp.lang.javascript/msg/ec3b0365d4d3fa19

On UA sniffing:-

"I won’t go so far as to say never use browser detection based on user-
agent sniffing, because I do believe there are valid use cases."

....and furthermore:-

"Note: if you’re considering user-agent sniffing, I wouldn’t recommend
worrying about user-agent spoofs. You should always honor exactly what
the browser is reporting as a user-agent. My approach has always been
that if you tell me you’re Firefox, I expect that you act like
Firefox. If the browser identifies itself as Firefox and doesn’t act
like Firefox, that’s not your fault. There’s no point in trying to
second-guess the reported user-agent string."

....and this:-

"So the recommendation is to always use feature detection whenever
possible. If it’s not possible, then fallback to user-agent sniffing
browser detection. Never, ever use feature-based browser detection
because you’ll be stuck with code that isn’t maintainable and will
constantly require updating and changing as browsers continue to
evolve."

....and I really detest the whole "I'm okay, you're okay" attitude that
exists in this industry:-

"I really didn’t mean to pick on MooTools when I first started writing
this post. It just happens to present a really good learning
opportunity for other developers. The MooTools developers are smart
folks who I’m sure are continuing to work to improve their library and
actively support their large user base. We all go through a similar
learning curve, and we can all learn from one another."

LOL. Mootools is as hapless as they come. Nobody learns anything
from such coddling. It's like none of these guys can stomach
criticism, no matter how valid. And, of course, he's also selling
some (bad) book on browser scripting (who isn't these days?)

"I’d also caution that user-agent sniffing isn’t as fragile as you
make it out to be. Any program, when written poorly and without the
proper amount of insight, is bound to fail. Many user-agent sniffs do
fall into that category but that doesn’t mean it can’t be done
properly (for instance, I show a safe way to do so in my book)."

This is at the end of _2009_, for God's sake. Reading it, you might
guess it was written in _1999_.

A few months earlier, he was pontificating about a bug in Dojo that
should be _very_ familiar:-

http://semicolonreport.blogspot.com/2009/10/why-feature-sniffing-sample-from-ie8.html

var featureSniffClassNameAttributeIsClass = function () {
var d = dojo.doc.createElement("div");
try {
d.setAttribute("className", "c");
var h = d.outerHTML;
// if setting className on a node alters the class, we are on
IE6 or 7
var convertClassToClassName = ! /classname/.exec(h.toLowerCase
());
return convertClassToClassName;
} catch (e) {
//probably we are on a non IE browser because an error
occurred
return false;
}
};

I'm supposed to copy a pale imitation? I don't think so.

 

[David Mark]

David Mark wrote:
David Mark 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 might consider breaking up the assertions into groups of tests, or
test cases. One for the wrapper, one for properties, and one for
attributes. I would probably consider putting each test case into a
separate document, so that each document is simpler.

A test case has a setup, a teardown, and one or more named test methods..
Each test function tests one specific thing and has one assertion per test.

Tests  (test functions) do not affect other tests.

An HTML template can be used to prevent tests from affecting other
tests. The way it works is a setUp/tearDown "sandbox" resets the
innerHTML of the template div. This allow for each test do to anything
in there without affecting other tests. A template might not work for
your specific "attributes" test, but can be useful for most things.

<div id="template">
   <a id="testLink">a</a>
</div>

var template = document.getElementById("template"),
     templateHTML = template.innerHTML,
     testLink;

var myTestCase = {
   setUp : function(){
     testLink= document.getElementById("testLink");
   },

   tearDown : function(){
     template.innerHTML = templateHTML;
   },

   testGetHref : function(){
     Assert.areSame(null, testLink.getAttribute("href"));
   }

Resetting the innerHTML (in tearDown) means that test1 can do anything
inside that template without affecting test2. Tests should never affect
each other.

There's not a chance in hell I would mix up innerHTML machinations in
the tests like this.  I would (and did) use a distinct "template" for
each set of tests.  No need to try to put Hunpty Dumpty back together
each time.  

[...]

The problems in the design of the YUI Test are solvable; it's not like
he painted himself into a corner.
Who?

Nicholas wrote that.

Zakas?  I wondered who that was.  I recently read some opinion by him
(on browser sniffing IIRC) that was so outrageously ignorant and
confused as to insult my intelligence.  Oh, I remember.  It was posted
less than two weeks ago:-

http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-bro...

Cross-browser scripting is a _very_ small town.  This ridiculous
article was offered up as a "good example" (for me!):-

http://groups.google.com/group/comp.lang.javascript/msg/ec3b0365d4d3fa19

On UA sniffing:-

"I won’t go so far as to say never use browser detection based on user-
agent sniffing, because I do believe there are valid use cases."

...and furthermore:-

"Note: if you’re considering user-agent sniffing, I wouldn’t recommend
worrying about user-agent spoofs. You should always honor exactly what
the browser is reporting as a user-agent. My approach has always been
that if you tell me you’re Firefox, I expect that you act like
Firefox. If the browser identifies itself as Firefox and doesn’t act
like Firefox, that’s not your fault. There’s no point in trying to
second-guess the reported user-agent string."

...and this:-

"So the recommendation is to always use feature detection whenever
possible. If it’s not possible, then fallback to user-agent sniffing
browser detection. Never, ever use feature-based browser detection
because you’ll be stuck with code that isn’t maintainable and will
constantly require updating and changing as browsers continue to
evolve."

...and I really detest the whole "I'm okay, you're okay" attitude that
exists in this industry:-

"I really didn’t mean to pick on MooTools when I first started writing
this post. It just happens to present a really good learning
opportunity for other developers. The MooTools developers are smart
folks who I’m sure are continuing to work to improve their library and
actively support their large user base. We all go through a similar
learning curve, and we can all learn from one another."

LOL.  Mootools is as hapless as they come.  Nobody learns anything
from such coddling.  It's like none of these guys can stomach
criticism, no matter how valid.  And, of course, he's also selling
some (bad) book on browser scripting (who isn't these days?)

"I’d also caution that user-agent sniffing isn’t as fragile as you
make it out to be. Any program, when written poorly and without the
proper amount of insight, is bound to fail. Many user-agent sniffs do
fall into that category but that doesn’t mean it can’t be done
properly (for instance, I show a safe way to do so in my book)."

This is at the end of _2009_, for God's sake.  Reading it, you might
guess it was written in _1999_.  

A few months earlier, he was pontificating about a bug in Dojo that
should be _very_ familiar:-

http://semicolonreport.blogspot.com/2009/10/why-feature-sniffing-samp...

Oops, apparently that wasn't him. Must have gotten my bookmarks mixed
up.

 

[Garrett Smith]

David Mark wrote:
David Mark wrote:
David Mark 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. The test aassertions shouldbe broken up into
test functions with one assertion per test. The test functions should be
organized into test cases. You might even want to organize suites, too,
but a good first step would be test functions and test cases.

[...]

Oops, apparently that wasn't him. Must have gotten my bookmarks mixed
up.

YUI Test does not use browser sniffing. There was one, about a year ago
or so, but he took it out after I showed him a different way. The test
runner runs in IE5.5 and Blackberry, and, despite what the author
continues to misinform about Opera mini, setTimeout does work there
(though apparently the duration is limited to 2000 ms). I have tested
Palm Pre Webkit, Opera Mini, Blackberry9000, IE5.5. The async stuff is
troubled in BB9k because of the timing strategy (should have used a
Timing manager)

YUI Test has other shortcomings.

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).

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.

 

[David Mark]

David Mark wrote:
David Mark wrote:
David Mark 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.

The test aassertions shouldbe broken up into
test functions with one assertion per test.

There is only one assertion per test.

The test functions should be
organized into test cases. You might even want to organize suites, too,
but a good first step would be test functions and test cases.

There's nothing more that needs to be done to those very simple tests.
There's just nothing to them (e.g. read an attribute, assert it equals
the expected value, repeat ad nauseam).

[...]

Oops, apparently that wasn't him. Must have gotten my bookmarks mixed
up.

YUI Test does not use browser sniffing.
Good.

There was one, about a year ago
or so, but he took it out after I showed him a different way.
Good.

The test
runner runs in IE5.5 and Blackberry, and, despite what the author
continues to misinform about Opera mini, setTimeout does work there
(though apparently the duration is limited to 2000 ms).

It would seem a prerequisite for tests to run in virtually any browser.
God knows, I don't need that guy to show me how to write cross-browser
scripts (asynchronous or not).

I have tested
Palm Pre Webkit, Opera Mini, Blackberry9000, IE5.5. The async stuff is
troubled in BB9k because of the timing strategy (should have used a
Timing manager)

I don't find that particularly intriguing.

YUI Test has other shortcomings.

I bet.

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?

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.

 

[Garrett Smith]

David Mark wrote:
David Mark wrote:
David Mark 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.

| 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.

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.

The code would be easier to follow if you break it up into test functions.

var uriTestCase = {
testAHref : function(){

},
testLinkHref : function() {

}

// etc.
};


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).

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.

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.

[...]

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?

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.

Here is an example of a good test I wrote the other day:-

| testNamespaceOther : function() {
| APE.namespace("other");
| YAHOO.util.Assert.isObject(window.other);
| }

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.

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.

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 probably won't see much value in testing until you get some
experience doing it.

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.

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.

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).

 

[David Mark]

David Mark wrote:
David Mark wrote:
David Mark wrote:
David Mark 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.

[...]

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?

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).

 

[Erwin Moller]

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

 

[David Mark]

David Mark schreef:



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).