Tape: Can't get Tape to work, installs but can't figure out how to use it.

[teckel12]

With node.js shell in the project's root directory: npm install tape --save-dev

In js file added: var test = require('tape');

I get this error in the browser's console: Uncaught ReferenceError: require is not defined

Trying it from the node.js shell, I enter tape tests/**/*.js as stated in the readme

I get this error: 'tape' is not recognized as an internal or external command, operable program or batch file.

Is there a more basic set of instructions that can take a user from zero to using Tape? Thanks!

[ljharb]

The basic instructions are for invoking it in node - to run it in the browser, you'll have to run it through a bundler like browserify (recommended) or webpack - refer to those packages for documentation.

[teckel12]

Wouldn't running it from the node shell with tape tests/**/*.js be running it from node? Trying to follow the docs, and it appears that's what I'm supposed to do. See my message above with the error I get.

[ljharb]

Ah! When you've installed it locally, you can't run tape by itself - you'd add it to an npm run-script, and invoke it that way.

In other words, your package.json should have a scripts section with something like:

"scripts": {
  "test": "tape 'tests/**/*.js'"
}

and then npm run test (or, just for "test", npm test for short) will invoke it.

[teckel12]

Got it, will try on Monday.

[ljharb]

I'm going to close this, but we can certainly keep discussing here if you have more questions about node-based developer workflows for web dev.

[teckel12]

Still no joy. I thought going with a simple unit test tool would be simple. I guess it's more designed for advanced users, which is a shame considering unit testing would be more useful to non-advanced users. A good reason not to unit test, it's too difficult to figure out HOW to unit test.

[ljharb]

Can you elaborate on what part isn’t working for you?

The “scripts” thing is a basic part of node dev; you don’t need the tape runner at all though - just node test.js should work for a single file.

[teckel12]

@ljharb I can npm install tape --save-dev, which installs Tape without a hitch and adds it to my package.json devDependencies. From that point I'm lost. The usage section in the Readme I guess doesn't apply for my kind of setup (although the only install method shown is exactly what I use).

I believe the instructions are written for someone who already understands how it works, instead of showing someone how to use it for the first time.

Maybe some background on the project I'm trying to use Tape with would be helpful. I'm writing a browser-based part management tool for an engineering company. It's written with PHP/SQL Server back-end, and a JavaScript/Vue front-end. I'm using gulp for development (sass, auto-prefixer, browser-sync). I'd say a fairly common and easy development platform.

I'd like to add in some unit testing but I can't seem to get the information I need to get going. After install, how do I get Tape to know all of my files where all the JS is? There's JS in probably 30 different files for each part of the tool.

I guess it could be that Tape just requires a high proficiency bar to understand and use. At least far too high for me. Is there an easy unit testing tool where I can install, add a few lines and test? If that's not how it works, I could build my own unit tests I guess.

[ljharb]

I wouldn't say it's a high bar.

Your project needs a package.json (sounds like you've got it).

At that point, you write your test files. Each single test file requires tape, and whatever you're testing, and makes it's assertions.

Then, to run one of your test files, you do node path/to/test/file.js. The tape runner is for passing multiple file paths, and/or globs - but it's not necessary, just more convenient (rather than node test/1.js && node test/2.js etc).

https://github.com/substack/tape/issues/406#issuecomment-340140083 describes how to add a "scripts" section to your package.json so that you can npm test, and it will run tape 'path/to/files/**' for you (or whatever you've configured).

Then, lastly, your CI should run npm install && npm test.

Every single tool in the JS ecosystem will be as involved, but likely much more so, than this - this is just how unit testing is done in javascript. Anything you write yourself is likely to be specialized to your understanding and use case, so while you're free to do it, I'd strongly discourage you from reinventing the wheel.

[teckel12]

I added the scripts section to my package.json. I created a tests folder with a single file sample.js which includes the example from the Tape Readme. Running npm test I get:

> [email protected] test C:\Dev\PiMP
> tape 'tests/**/*.js'

Doing a node tests/sample.js I sometimes get the results on in the Readme, but other times I get an error.

So I really don't get far. And I really don't get how I would use Tape to test my JS. If I was to write my own, I would call a function and compare it to what I would expect back. That would seem really simple. But how would one do this with Tape? It's like something crucial is missing.

[ljharb]

Yes, that's what you do with tape. Would it help to look at an example project? https://github.com/ljharb/daytime/blob/master/package.json#L8-L9 runs the test file, which has tests like this

[teckel12]

So in my sample.js I do the require tape and then try to require one of my files I wish to do a unit test on a function. So I try and do:

require('../views/home.php');

But it seems to fail on the html markup. Must it be only JS? With Vue you typically have html markup and JS in the same file. It has a php extension because sometimes something server-side needs to be done as well.

Maybe Tape just isn't designed for a mixed markup/php/Vue/JS type of web-based development as it requires vanilla JS?

[ljharb]

Yes, JS should only ever go in .js files - as a best practice (for many years now), you'd never do anything PHP inside your JS.

In other words, nothing in the ecosystem will work on anything that's not a pure standalone JS file, because that's been a best practice for a very very long time.