mochajs / old-mochajs-site Goto Github PK

The section that's a copy of mocha --help needs to be updated, as must the detailed explanation of --no-exit (now --exit), if nothing else. Helps with mochajs/mocha#3044

sorry, you anti-google zealots

add new logo

I've read in a couple articles about font sizes on the web, and it occurs to me that the font sizes used on the site are probably too small. The main text is 14px. I would like to increase this to 16px (or whatever em that typically works out to). The "code" text is 12px, I believe, and should be as close to the main text in size as is feasible (I think?).

Any other opinions?

dunno.

cc @dasilvacontin @xdamman

In the index.md, it says...

Pending tests will be reported as such.

...and that's all it says. There is no example output provided with the "as such" claim.

need to update docs with new features and changes.

it should work and look better on mobile and older browsers.
also: accessibility.
wham bam

Here: https://mochajs.org/#the-test-directory

Currently says:

By default, mocha looks for the glob ./test/*.js and ./test/*.coffee, so you may want to put your tests in test/ folder.

This is inaccurate in one big way and one small way.

Big way: .coffee no longer used by default.

Small way: technically, the default glob is test; when a directory is specified Mocha looks in it for *.js files (or *.{js,<other extensions from --compilers}) or for **/*.js files when --recursive is specified. This is really only important if you need to understand adding *.{<extensions>} when replacing --compilers or if you need to understand --recursive, but we do occasionally get people confused about the interaction between globbing and --recursive...

It's documented on http://mochajs.org/, but it took me a few moments to realize that a release hadn't been cut since the PR was merged.

Caps... erm, probably aren't the best design choice for case-sensitive material:

"Wait, which one is -r and which is -R?"

It should mirror whatever's in the main repo for now (and later it should be expanded & organized)

https://mochajs.org/#undocumented-reporters documents the XUnit reporter. Instead of the section being labelled "XUnit", it is labelled "Undocumented Reporters". Since the section documents the XUnit reporter, the XUnit reporter is not undocumented as the section name implies.

Amusing anecdote: this reminds me somewhat of the Liar Paradox, but I think it can be resolved without needing to understand the Incompleteness Theorem. (...It is possible I am using a non-standard implementation of the amusement module...)

in this pull the sender mentioned the docs were out-of-date w/r/t testing mocha itself

from mochajs/mocha#1387

summary:

Mocha is a great test framework for Node projects, but it's also a great test framework of web projects. However, the front page of the Mocha site makes no mention whatsoever of the web-based usage, which is somewhat confusing for non-Node users:

Installation

Install with npm:

$ npm install -g mocha

If you just took a few lines to say something to the effect of "download mocha.js and mocha.css from the GitHub page here, then include both files on an HTML page before including your test files" I think it would be really helpful to non-Node users.

Once mochajs/mocha#2618 is complete, update the docs here to reflect the findings.

from mochajs/mocha#1115

Not sure if it is needed, but it may be worth noting that due to shell expansion, glob patterns should be wrapped in single quotes on unix shells.

mocha -w -r should 'test/**/*.js'

Using that would render the --recursive flag useless.

from mochajs/mocha#1298

There is very little information that explains how to use the programmatic interface. All that is really mentioned is this wiki page that provides an example. It would be nice to see explicitly what is available like this (for example).

output help after install via other means

Invariably when I land on the Mocha site and search for a thing, I land on the "Features" list and am dismayed that it's not clickable. IMO the features list should link to the relevant feature docs, similar to the TOC.

I'm happy to look into this if there's no objections.

from mochajs/mocha#1783

relevant:

in summary:

• The current site is not licensed
• Therefore nobody can use or modify it in any way
• Furthermore, anyone who forked Mocha and checked out the gh-pages branch could be sued by TJ
• We should license it for reuse
• We can't license it MIT, because MIT applies to software only
• So let's license it under a CC license
• TJ will still retain copyright, but the CC license cannot be revoked

When I call done() passing a non Error instance (let's say an error Object Literal, for instance) I get the following message:

done() invoked with non-Error: [Object object]

If the contract is that you should pass an Error instance to the async done handler, then that should be documented. I couldn't find that when looking at the site, only looking at the internals (which, as we all know, should not be relied upon).

If you pass a String (done("it should not do this")), according to the source, it is supposed to be casted accordingly, but then the result will be something like:

done() invoked with non-Error: it should not do this

That is interpreted as a mistake, but then the docs should reflect what should be done to prevent that mistake.

Below is the relevant piece of code from source (2.4.5):

function callFnAsync(fn) {
  fn.call(ctx, function(err) {
    if (err instanceof Error || toString.call(err) === '[object Error]') {
      return done(err);
    }
    if (err) {
      if (Object.prototype.toString.call(err) === '[object Object]') {
        return done(new Error('done() invoked with non-Error: '
          + JSON.stringify(err)));
      }
     return done(new Error('done() invoked with non-Error: ' + err));
    }
    done();
  });
}

TL DR;

Document that done accepts either undefined or an Error object to reflect the current undocumented behavior.

Travis is/was running (I just disabled it), but there's no configuration present, so any PR would be marked as failing. So someone needs to find the standard Travis setup for testing a jekyll site and use that.

https://mochajs.org/#getting-started

Problem: getting started has you install mocha locally, make a test dir, and write a test, but doesn't show you how to run it nor how to set up npm test.

Suggestion: instruct users to add a test script to package.json such as:
If mocha is installed locally:
"scripts": { "test": "./node_modules/mocha/bin/mocha" },
If mocha is installed globally:
"scripts": { "test": "mocha" },
And then run it with $ npm test

Expected: some instruction on how to run tests after installing mocha.
Current:

@DenisGorbachev writes:

http://mochajs.org/#editor-plugins — it would be great if you had mentioned Wallaby.js with an intro video here. Much better than default JetBrains test runner.

from mochajs/mocha#1281

The option was added in 1.21.0, but it is not documented yet.