Couple of thoughts: 1. NO LONG ASS TEST NAMES.
2. I'd still argue that we shouldn't be using a browser as our native test runner. We'd have to give up the little green check marks that make us all feel warm and fuzzy when tests pass, but the browser is a huge ass confounding variable. To me, a proper test suite would be run from directly from the command line. We have the hacked together test runner, but not many people seem to use it regularly because we have the fancy green check marks. If people want to have a set of tests for a browser as in "Your browser must support this set of operations to be used with CouchDB" I'm all for it, but other wise its just adding headaches. Also, making sure that all data is run from the command line means we can integrate it into a build bot. This means we know who to yell at if someone breaks trunk. This is a good thing IMO. 3. My spoon is tooooo big! Or the tests in this case. But its funnier with the talking banana mental image. Making test cases smaller and more focused is a good thing. Some sort of shallow directory layout could be useful for categorization. And I'd argue for one file per test. 4. Crazy idea on tagging. This is a bit off the deep end, but it'd be kinda neat to have tagging support for tests. then if you have 5 seemingly random tests fail you'd realize that they all touch the _uuid's endpoint or something. Just a random thought. 5. Also, there's an issue on JIRA to get a page so that people can write tests cases from within Futon. Hopefully this would motivate new people in the community to write tests that they can then upload to JIRA (manually, of course, lawyers ftw). 6. I don't really have an opinion on couch.js. I can see both Damien and Chris's arguments but I'm not overly concerned. When I was playing with ajaxy bling with CouchDB I was just using jquery's normal ajax support without any sort of library. The API is so thin I didn't even stop to think that I'd want a library in the first place. Granted I'm a bit familiar with the API. 7. NO DAMN PARAGRAPHS FOR TEST NAMES. 4SRS! I have no idea why I made that a numbered list. But I'm too lazy to change it now. HTH, Paul Davis On Fri, Feb 13, 2009 at 1:02 PM, Damien Katz <[email protected]> wrote: > So there have been some grumbling that the test suite could use some > changes. > > A small problem I see is the use of couch.js in the tests. I'd personally > like to remove the Javascript couch.js library usage from the tests and > instead use more naked HTTP calls and simple sub-routines. > > My biggest reason is clarity, the tests are like documentation and by > removing a layer of abstraction the tests are easier to understand for > exactly what they are testing. A simpler (if longer) test implementation > makes it easier to build and debug libraries for other platforms. > > My other reason to drop couch.js from the test is it risks becoming the > defacto JS library, and not a very good one. Because we are trying to keep > it simple for the tests, it doesn't have lots of features that would be more > useful for real development (like async support). I'd prefer couch.js be > exactly what it needs to be for useful in a browser without serving the > needs of the test suite. > > I'd like to know what others thing about that idea. It's a big task, lots of > code in the test to modify. > > A bigger problem is the tests are just getting numerous and not very well > organized. And it's only getting worse. I'm thinking we need to categorize > the tests somehow to run subsets easily, but I don't have any concrete > ideas. Suggestions welcome. > > -Damien > > >
