ashleygeorgeclarke commented 9 years ago

I don't write any tests for my code. I know, I'm a bad person.

I would like to learn how to write effective tests and thought maybe there would be other people in the group that would also enjoy a talk about this.

I would like to see how they're incorporated into workflow, and some good use cases in Node and Angular (or similar).

Would also like to be convinced about why/how it's so important.

Cheers, ash

MauriceButler commented 9 years ago

I can cover unit testing in node.

The same tools and practices work for front end JavaScript too with some additions for browser specific stuff. (DOM, etc)

marklawlor commented 9 years ago

I'd love this talk as well, especially talking about workflows, but I think we should split this talk up over a couple of weeks. Its quite a broad subject and and the information is going differ depending on the size of the javascript project (i.e. small library compared to web application).

Week 1:

Fundamentals of testing + test driven development
What is a good test?
Why test a project
Explain how writing tests can actually speed up development
Basic examples of testing

Week 2 - Testing workflows for prototyping/small libraries:

Using tape
Using nodemon for console
Using beefy for browser
Using smokestack for automated testing (Shoutout to @timoxley, if he could provide some info it would be awesome)
Moving from local testing to continuous integration (smokestack -> Saucelabs)

Week 3 - Testing workflows for larger applications

Testing libraries (Jasmine, Qunit, Mocha, Karma)
Grunt / Gulp workflows for local testing
Local CI testing with jenkins
Remote CI with githooks

ashleygeorgeclarke commented 9 years ago

Is it ok if I record this and upload to youtube?

timoxley commented 9 years ago

great initiative. @marklawlor what info you need?

MauriceButler commented 9 years ago

Sounds Good. Our basic test stack incorporates smokestack too so might be able to shed some light

marklawlor commented 9 years ago

@timoxley I've yet to use smokestack (its on my todo list), so I was hoping you could provide some example projects and/or basic info on what problems its trying to solve and how you use it within your workflow. When I wrote that post I wasn't aware of anyone in Brisbane who was using Smokestack, but it looks like@MauriceButler could probably answer these questions. I also thought Smokestack would be good for @kevdesign to give you and CampJS a shoutout :+1:

@MauriceButler If your still interested in doing this talk, I'm happy for us to co-present or split up these talks. I'm not sure if you were keen for this becoming multiple talks...

iamkevinv commented 9 years ago

I'm super pleased to see this activity guys :-) I've been keeping a watchful gaze.... Can I add this to the announce for the next BrisJS? Will we be able to get ready?

marklawlor commented 9 years ago

@kevdesign When is the next meetup? The first Monday of April is a public holiday (Easter Monday) and I'll be away.

ArtemGovorov commented 9 years ago

I could present my tool wallaby.js for JavaScript continuous testing (both node and browser). The tool is commercial, however is available for free at the moment.

govpack commented 9 years ago

how about this

write the the code
run the code
when it works the way you want it to, then you're done!!

running the code is THE test, you were doing it right in the first place!!!

the opportunity cost of "writing tests" is "getting things done" which would you prefer? if you think tests are that important -- then go back to school writing tests means you think your code is super important -- it isn't

hell yes, i'd like to see http://wallabyjs.com if red/green refactoring insteps [1+2+3] above can be combined into one integrated seamless process, then maybe testing isn't the self indulgent, self important, masochistic, time wasting step i suspect it might be... but maybe i include more tests in my process than most, so maybe i'm an advocate of some sort of testing, but not BELOW the level i'm willing to consume as an end user or the API, and having a way to leave those API/CLI tests in place as a layer of documentation that can be added to - if a new feature is added.

I'm happy doing TDD as long as it stands for "TASK Driven Development" where one such TASK might be to see the results of all these tests people have been writing. How would one test all the tests in npm, so we could see what we really think about testing, since there may be value in it as active documentation (or in some cases "the only documentation") that more fully exercises an api.

install all of npm (that should include most of the testing frameworks required as well)
loop over all the modules looking for tests
decide how a test files should be run [???]
run the tests
display the results

only then will i know what i think about tests as other people are doing them

demo

xwipeoutx commented 9 years ago

@govpack I'm not sure this topic is about the merits of unit testing, rather on how to write effective and maintainable tests.

As for "running all the tests for every node module", the result (I would hope) is simple "all tests passed" for every module. I'm not sure what kind of results you're expecting there.

Do hit me (or I imagine any other test nazi) up next meetup if you want to discuss the merits of automated testing, and the importance of "the code" - I think you'll find we have starkly different views on that, so it ought be an interesting discussion ;)

govpack commented 9 years ago

"the most effective and maintainable test is one i didn't have to write" I aim to answer the questions: what? where? how much? how many? and some of the why, with a view to generating active documentation from any tests that may be present. It's an exercise to cure my ignorance and satisfy my curiosity and to better avail myself of what's in there: the exceptional parts the better parts etc. If those are some the building blocks it's about time we did more of a stocktake and had more of a clue.

If it was a choice between having 10% more apps or 10% more programmer time devoted to writing good tests, i would rather have 0% tests and take a 10% bigger bite out of the future and what this stuff can do for us.

Someone saying "I need tests" is like a person saying "I need a cigarette" (ie not really). Or like religion "it helps, but I can't prove it". It's a side step, and in many cases an unnecessary distraction. I'm all in favour of testing the whole way thru, but perhaps in a different way. If tests are valuable then they ought to be made more readily runnable and writeable so more people can participate.

The pain of writing more code, or code about code, what next: "tests to test the tests?" does the same logic hold up there as well? it's all just code isn't it? it's all important isn't it? is testing really some sort of universal good? NO way, so i don't think it should be sold as such. The choice to write more code should be minimized as soon as possible.

I think the end use cases [and more of them] are more important. but each to their own, people are already doing lots of testing so I'm curious about to the hows and whys etc.

The way it comes up about people being "bad" or feeling "guilty" about not doing testing, sounds like a religion, or if there are any nazis involved, lol, at that point I'm happy to say that NOT doing any unit testing is ALSO a perfectly good/valid/sound option, testing is like a bad drug: "just say no". It's like procrastination, because it avoids the actual task, it's a superfluous/frivolous weakness, like github comments.

govpack commented 9 years ago

Okay lets get ready to test!!! just run this simple command, and we should have most of what we need:

npm install -gf mocha grunt _mocha lab jshint broccoli taper zsh tape tap expresso testling set browserify beefy synct asynct component echo say mkdir faucet cd glslify test rm testem zuul open istanbul gnode standard vows karma fox prova tapes tessed cat watchify mochi gulp tar if nave please illuminati mochify nodeunit sh eslint bower simpleunit qunit gt true false pakmanager served mochatest for doubleshot sherlock hydro mini kensa cake ember find phantomjs ls jam tinytap jspecs jison jsonlint jest blow covert proof promisebench sudo jake exit count cult ndocs coffee tnpm webpack stylecow jsxhint python jscs return iojs whiskey env testla m ntsc ulimit export none source rdir pushd batshit jsx retire alias anvil it lol jasminum sjs mocha_phantomjs jasmine bash bake buster luvit jslint atomify brunch bulletproof atma nope testjs jpm pogo moka doctest 6to5 firefox no autodoc clear feicon nodejs cr na command null rake ilinco lincoui npmmodulecommand arch git macchiato jstest coffeelint forever washington unitjs tessel fdm plz ytestrunner grunter protractor printf unset lesscap chasis pliers six stello slush chromedriver perl start tank rapid is ant testacular hues lua runtests unjip slake demo markdown_code mycha nothing colortape mjnw tmod itag js ppcompilation i18n auto_labels export_labels import_labels semistandard hello lumia moqi tsc kal shunit2 cgulp cfx xappconfig moonshine i cp chmod barrier listentoroomevents rmdir express wow trireme rblint copy taster time pm pt foreman sft fig doodles yuitest tet nodefilebrowser index this weibo get_licenses jsmd srunner supspr sm minijasminenode2 wct eee lein what cssv var nodemon slice2js jcool cgit prove binggege a s mocah nfe nmake mongod sss testpilot beans cqlsh grep ibrik nfjvndobn cover waf ntest vow marked jet mytestcommand ashleshajs ufo t kxbrand cli microfield toy lisp dd m139test ee pera rtyrty napstart ggg icake ubs trtrtr harbors linbin tpmath tpackmath jody rason_node help pybot super spider testcmd leet _coffee delight testcommand sayhello jemoeder fuck backbone web5 abcedf sl dgm haha domagic ff ctest getrepos aaa ss cds insightmine build jdm resume yuhhu should jin go kazikai kingman package ll al testa_a fawkes lsc lee lsf lulin lyl fifa addition adf tesst asdf mupre testthis list boonya show fpi casperjs server y elixir blkswan subtraction lai hahah ran dddd bundle pin xx ppm fntest testreporter rujianfang which who samplenandkishorpackage jm sarafan tests jljlj grun showredirect test1 testit so space ninja subtype d shost testtfs yok sdada just tugenhua not oo comm tescommand watchers xasl new zap asd sa run zt

which are the first words as collected from 118301 "npm modules" scripts.test fields some are system tools that clearly won't work, your mileage, my mileage etc, so i find the whole thing a little bit funny, like tests are just more code (code running code which i think is great)

but because it's code, a lot of people are going to disagree and get religious about things (like what actually belongs in npm, i think it should be a pure set of relatively safe "node packages" and CLI tools that run in node.exe at the very least) but that decision has already been made, such that an npm package is anything with a package.json (it can be empty or have browser assess or files of any kind, some have "node modules" which is any javascript that require('xyz') can import via the thing's module.exports

an npm package can be empty, with or without code with or without tests

In fact of the 118301 npm packages i looked at -- 52% (61106) had some sort of scripts.test property set --- and 21% (25201) did not have any scripts.test, i think there's some other less common props for coverage etc

so i start printing out what npm test says for each module folder and there's lots of stuff that doesn't resolve but lots of tests that DO . Since there are so many modules, so it's easy enough to ignore the ones that don't work, and focus on the ones that do, errors are welcome, they are just a results of a different kind.

there modules that actually work but the tests fail to run
and tests when run that will crash the process
sometimes it will say: "npm ERR! Test failed. See above for more details." but there are no more details above, is this another religious thing and we have to look higher up?

i think it's good that people have take the trouble to explain what they are doing with their tests many have a set of explanations in stages (i had to i -gf tap vows etc, because i don't think it got thru that big list, lol)

then again there's stuff like...

┌─────┐1841.20─────xurl──────────────────────────────────────┐ ├── ♫ a simple url parser ├── ♫ mocha

xurl@0.0.1 test mocha

xURL √ can parse a full url √ can parse an empty url √ can parse an empty path √ can parse a url without a protocol √ can parse a url without a port √ can parse a url without a port √ can parse a url without an empty query string √ can parse a url without a hash √ can parse a url without an empty query string

9 passing (16ms) ──────────────────────────────────────────────────────────

which we can do with something like:

Url=require('url') opt=Url.parse('http://en.wikipedia.org/w/index.php?title=List_of_file_formats&action=raw') util.inspect(opt)

so i just sort of cringe at what is going on in the testing space, like are you going to test "string".split('')?I'd say see that it works and only go back in if it doesn't -- no need for tests, since there are always going to be surprises that no amount of testing will cover

Or ┌─────┐1847.20───────spirit-requirejs──────────────────────────┐ ├── ♫ A javascript module loader based of requirejs for the spirit static file generator. ├── ♫ mocha

spirit-requirejs@0.0.2 test C:\Z\X\114\B\2\N1847\Ax\20 mocha

spirit-requirejs √ should write to destination folder . (88ms)

1 passing (89ms) ──────────────────────────────────────────────────────────

like if it doesn't "write to destination folder" is the world going to end? presumably, if it matters you are going to know about it some other way like "there's no output in the folder, dohhh, what the heck is going on?" some thing isn't write, i mean right, right?

or this one that formats your disk drive (as a test)

┌─────┐1858.17─────parsetition──────────────────────────────────┐ ├── ♫ Parse common disk drive partition formats ├── ♫ node test

fs.js:429 binding.open(pathModule._makeLong(path), ^ TypeError: path must be a string at Object.fs.open (fs.js:429:11) at Object. (C:\Z\X\114\B\2\N1858\Ax\17\test.js:13:4) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Function.Module.runMain (module.js:497:10) at startup (node.js:119:16) at node.js:906:3 npm ERR! Test failed. See above for more details. ──────────────────────────────────────────────────────────

it says "path must be a string" Now node or iojs doesn't have a "test" command but will try to resolve that to a "test.js" which is there, so this package has tests ;-) so "tests.js" contains

var pt = require("./"), fs = require('fs');

var b = new Buffer(512); b.fill(0); b[0x1FE] = 0x55; b[0x1FF] = 0xAA; pt.parse(b);

var IMAGE_PATH = process.argv[2];

fs.open(IMAGE_PATH, 'r', function (e,fd) { if (e) throw e; else fs.read(fd, Buffer(512), 0, 512, 0, function (e,n,d) { if (e) throw e; else console.log(pt.parse(d)); });

});

but that script won't receive an argv[2] from npm test, since the command was just "node test" but if i throw in a flash drive at D: and run node test.js D: it will say...

C:\Z\X\114\B\2\N1858\Ax\17\test.js:16 if (e) throw e; ^ Error: EINVAL: invalid argument, read at Error (native)

or node test C: C:\Z\X\114\B\2\N1858\Ax\17\test.js:16 if (e) throw e; ^ Error: EISDIR: illegal operation on a directory, read at Error (native)

or node test F C:\Z\X\114\B\2\N1858\Ax\17\test.js:14 if (e) throw e; ^ Error: ENOENT: no such file or directory, open 'C:\F' at Error (native)

so there's just no accounting for stuff that doesn't work and no amount of testing is going to fix it (esp if it's expects some sort unix based OS, perhaps a decent test would tell me, but that's not reality)

Returns pertinent info for the partitions on a volume.

the readme is about as helpful (like everything is there except the bit you'd want most)

parsetition

Returns pertinent info for the partitions on a volume.

Installation

npm install parsetition

Example

var pt = require('parsetition');
// TODO: …

API

TBD
License

Reuse under your choice of:

TODO: … OMG!!! some instruction on actually using the thing, why stop there? In American English, to be announced (TBA), to be confirmed (TBC),

it's funny, the library itself might be sound, it is a gift and a type of comedy

of course there's going to be MANY examples that restore the faith and do useful stuff and have good tests, as part of a multi step process where it is nice to have tests to indicate the various outputs along the way....

┌─────┐1868.16────────adagio.json────────────────────┐ ├── ♫ A MusicXML converter to the JSON format of the adagio library ├── ♫ node_modules/.bin/mocha --ui exports --reporter mocha-unfunk-reporter tests --slow 150ms --timeout 1000ms

adagio.json@0.1.0 test C:\Z\X\114\B\2\N1868\Ax\16 mocha --ui exports --reporter mocha-unfunk-reporter tests --slow 150ms --timeout 1000ms

-> running 3 suites

toAdagio basic MusicXML conversion.. ok part-group transformation.. ok direction transformation.. ok backup / forward transformation.. ok

mxl should inflate a mxl file.. ok should not be able to inflate this bad mxl file.. ok sould limit the max inflate size.. ok should deflate a xml file.. ok

toMusicXML basic MusicXML conversion.. ok part-group transformation.. ok direction transformation.. ok backup transformation.. ok

-> passed 12 of 12 tests (267ms)

............................................................................................................................... i think they are all worth outputting and coming up with a way to browse through them really quickly, or from 30,000 feet, or 64,000 feet if you're counting those of ALL the npm contributors, to which in general i say thanks, and good work!! ~ where there's a sliding scale on "good" never the less - the best of it is outstanding!!! and that differs for every person

import-mute: ERROR: expected ')' got 'm'
lazy-eval: OK
media: OK .....
parens: OK
strings: OK
errors/add-mixed-units: OK
whitespace: OK
selectors: ERROR: Unrecognised input

timoxley commented 9 years ago

@govpack The books below really sold me on the merits of testing, highly recommend you give them a read:

govpack commented 9 years ago

my unit has a leaky ceiling :( how can this help?

i wish the legacy of those old java heads was that we didn't have to repeat that stuff

i looked them all up on github and they are all shockingly unproductive!!!

(at least as far as github is concerned which probably isn't saying anything)

eierbaum-saalfeld-2009 1

govpack commented 9 years ago

the merits of testing would be:

for clarity and re-use
to better define a set of features
to track and document what you are doing
to provide guarantees about what you are doing
to get some structure around the inner workings and features
so you can move forward and improve things with more confidence
to get some visibility into what's happening which is hugely helpful
as numerous and varied as there are people using them

testing is like giving an application an awareness of itself, which is a good thing to survive version bumps and new environments, it's a roadmap of where things are working and where they don't.

the merits of NOT doing any extra testing are "you don't have to do that" which is also a brilliant option in many cases

"0/0 tests ran successfully, everything passed"

from an actual test run, which i like, because it's right

timoxley commented 9 years ago

What happened to your author productivity analysis @govpack? All I see now is Easter tree.

timoxley commented 9 years ago

I have wondered the same thing myself though, for every technology or practice that claims to be the golden path, none seem to be easy, obvious or without tradeoff.

It seems there's a mandatory minimum complexity in any significant software, beyond which you may only decrease complexity in one area by increasing complexity somewhere else, and you're gambling that the complexity you swept under the rug stays there.

govpack commented 9 years ago

i just thought i don't know these people, and i thought it was a bit mean, so i censored that out

github has only been a thing for six years (April 10, 2008; 6 years ago) and those authors have obviously made a decision to put their time and energy into other things: families, training, consulting, writing, etc, like zed shaw if he wants to paint and make music that's fine too

In the Era of single page apps and single functions as API endpoints it is quite easy to write an App or two a day, without even trying (like 500 apps a year) especially if it's part of a broader mission where lots of functionality is required which is massive progress on the way things used to be done, i've browsed and read bits of most of those books (c/c++,java patterns,code complete from Microsoft press), those guys are enthusiastic and progressive, i get the strong feeling that they want to be surpassed that's why they were giving everyone a push, i was being critical, due to some search for meaning of my own (there isn't any, or only that you bring oneself) and that i want to stay free from the cobwebs of old ideas

it's funny because complexity doesn't exist (it's only a label we attach) at least with a single page app one doesn't have to browse off into other files classes and sub classes, i'm happy with making apps that only take half a day to do, and to leave any refactoring to my subconscious mind to be applied to the next iteration/app that does something similar, and start fresh each time, i have some that are horrible UI state machines with too many parts knocking on other parts, but they work and surprisingly i can poke aroun and ADD new bits in [adding to the mess] but that also work, i'm waiting for the inside view in the dev tools that will some day show me what i did!! because at this stage goodness knows ~ but the runtime knows, so why doesn't it show us a bit more~ I imagine it would look something like a pin ball machine with data and events and things lighting up and changing

timoxley commented 9 years ago

i just thought i don't know these people, and i thought it was a bit mean, so i censored that out

Good call.

complexity doesn't exist

Can you elaborate?

the runtime knows, so why doesn't it show us a bit more

I too would love more visualisation tools, either for runtime analysis or during the design phase. UML and its ilk seem to have gone out of fashion, but I'm not sure there's any modern alternative for doing more structured planning before you start coding.

I've tried out http://drakon-editor.sourceforge.net/ and http://www.state-machine.com/qm/help/ but as you can see they belong to an era past.

I'd also like to be able to wire stuff up visually, and have simple code-gen. Ideally this could somehow work alongside an existing codebase rather than requiring total-buy in.

There's some efforts in the JS world:

But they both force their abstractions upon you and appear a bit too bloaty for me. Not sure what the answer is.

There's a powerful and apt view layer provided in http://jointjs.com/, which could be used except I have an unreconcilable prejudice against building anything on top of tools that use jQuery.

From a different angle you can use something like http://mrale.ph/irhydra/2/ to visualise the structures which are generated under the hood by v8.

govpack commented 9 years ago

Continuing to run the tests on all of npm

just completed a naive attempt at expanding out a package.json script:{test:path} and bin:{app:path} with a fallback to "npm test" Even with the npm source code i don't know how it arrives at a command to run doing this because a lot of the tools don't have globally available bash/cmd shortcuts on my path, so i try to find the folder+js file explicitly

re: "complexity doesn't exist" in nature there are no labels, there's no physics, chemistry, math etc, all just labels we bring to a situation, things just are what they are, we bring the labels and the complications (aren't they like features on a fancy watch) the thing isn't the label we give it, it just is what it is, so it isn't complicated, sure i find it complicated, quite often, but it isn't fast or slow, only in comparison to something else, the complexity will vanish from a different frame of reference.

on the todo list was to use the connected noflo zoomable interface for something, or joint.js (as used by noflo), or JSplumb (which maybe to it's detriment also supports old IE) hadn't heard of vvvvjs, 4 "v's" wow -- i always thought "w" should be called "double v" because thats what it looks like) avoiding that beacuse understanding noflo etc is still a bit of a jump

with svg and the ast stuff being easier to do, maybe soon we will at least have a diagram view synced to the current state of our code, at least as a navigation aid, or to re-arrange things, otherwise and for a long time yet the answer is to just keep fighting the text war, ascii/unicode can just express so much

in the future maybe there will be a tool to remove jQuery and just use the actual dom or smaller helper functions which i've always found much more pleasant (both java and .net now have the ability to compile to native code by including all the required things and avoiding the virtual machine, i think)

https://github.com/traceglMPL/tracegl

~ got open sourced a while back, before that it was this wicked 16 euro app that self updated itself and would hookup node debug activity to a browser canvas with some navigation and the ability to open edit the source code at that line like it says in the readme "The visualisation UI is available on http://localhost:2000"

have always wanted a universal autocomplete, In the mean time explainshell.com esp. for unix command is a bit of a mind blow the source is on github ~ it reads the man pages and splices them back in to interpret any command i gave it "tar -xzv -f file.tgz --strip 1 -C C:\ZZZ\" which also works on windows as part of the git tools, the --strip 1 removes the container folder, i may have that a bit wrong because i also have tar+' -xzv -f '+file+' --strip-components 1 -C '+DEST but anyway explainshell will try to explain your shell commands

http://explainshell.com/explain?cmd=tar%20-xzv%20-f%20file.tgz%20--strip%201%20-C%20C%3A%5CZZZ%5C

http://explainshell.com/explain?cmd=cut%20-d%20%27%20%27%20-f%201%20/var/log/apache2/access_logs%20%7C%20uniq%20-c%20%7C%20sort%20-n

screenshot 14

still testing....

┌─────┐─────────destiny───────────────────────────────┐ ├── ♫ Control the fate of your actions.

┌─────┐────completion───────────────────────────────┐ ├── ♫ Completion library for CLI commands ├── ♫ mocha

A command broken down into parameters √ is as expected

A partial command with one completion match being completed √ returns its match

A partial command with multiple completions being completed √ returns all of its matches

A partial command in junction with the item being completed √ returns the command's match

A terminal command being completed √ returns the command (for spacing)

A terminal command with whitespace being completed √ returns nothing

A terminal command with a completion function being completed √ returns the results of the completion

A command with a completion function completed after the command has already been used √ does not reply with the commands results

A many level command when completing an incomplete command √ returns the expected command

A command with terminal options completing a terminal option followed by a command √ does not return any matching commands completing an option √ does not return any values

dmod@0.0.4 test node test/runner.js

=== Processed 0 tests, 0 failed

=== in 0ms

=== SUCCESSFUL

runner.js contains..... require('unit-test').Suite.paths(__dirname, ['*Test.js']);

and i like 'unit-test' cannot find any tests matching that '*Test.js' pattern

https://github.com/dtudury/discontinuous-range ┌────discontinuous-range───────────────────────────────┐ ├── ♫ for adding, subtracting, and indexing discontinuous ranges of numbers [ 1-7, 9-12, 14-59, 81-100 ] 87

add sets √ should allow adding numbers √ should allow adding ranges of numbers √ should allow adding another DiscontinuousRange

subtract sets √ should allow subtracting numbers √ should allow subtracting ranges of numbers

var all_numbers = new DiscontinuousRange(1, 100); //[ 1-100 ] var bad_numbers = DiscontinuousRange(13).add(8).add(60,80); //[8, 13, 60-80] var good_numbers = all_numbers.clone().subtract(bad_numbers); console.log(good_numbers.toString()); //[ 1-7, 9-12, 14-59, 81-100 ] var random_good_number = good_numbers.index(Math.floor(Math.random() * good_numbers.length));

In summary i would be all in favour of hearing the: how/where/what/ when and why and with what people are doing their testing, there's some pretty trippy stuff in there!!

govpack commented 9 years ago

still doing the testing....

some of the more colourful language will be lost in translation from the console, and some of it isn't, lol

"This text should be bold cyan" "[ Bananas: LOGGY LOG! ] I should have a different log message"

~ again there will be tools to help with that, but i don't think this markdown box would oblige anyway i wonder if npm source code had a swear jar, at 50 cents, how much money would be in there? tho it would be like dogecoin.com wouldn't it, like 50 millionth's of a cent, because open source developers aren't paying, are they, 'cept with their time and their sanity that is

┌─────┐──────rex-shell───────────────────────────────┐ ├── ♫ A lightweight library for Node.js that will help developers display nice, pretty, colored messages in a console window. ├── ♫ TE:node ./test/rex-shell.test.js

[ rex-shell: Log ] Running rex-shell Test Suite! [ rex-shell: Log ] This is a rex-shell call without a specific function! [ Log ] I am a sample log message! [ Log ] I am one of multiple log messages! I am another of multiple log messages! [ Error ] I am a sample error message! [ Error ] I am one of multiple error messages! I am another of multiple error messages! [ Warning ] I am a sample warn message! [ Warning ] I am one of multiple warn messages! I am another of multiple warn messages! [ OK ] I am a sample ok message! [ OK ] I am one of multiple ok messages! I am another of multiple ok messages! [ Bananas: Success ] I am a sample success message! [ Bananas: Success ] I am one of multiple success messages! I am another of multiple success messages! [ Bananas: Application Error ] App error 1 App error 2 { error: { name: 'App 3' } } [ Bananas: App error 1 ] App error 2 { error: { name: 'App 3' } } [ Bananas: LOGGY LOG! ] I should have a different log message [ Bananas: You fucked up. ] I should be different as well [ Bananas: Shit went right! ] It's all good here! [ Bananas: Shit went right! ] Also good here! [ Bananas: WATCH YO ASS FOO! ] Warning message, ahoy! This text should be light red This text should be light green This text should be light yellow This text should be light blue This text should be light magenta This text should be light cyan This text should be light white This text should be bold red This text should be bold green This text should be bold yellow This text should be bold blue This text should be bold magenta This text should be bold cyan This text should be bold white

AshKyd commented 9 years ago

Can we reign this in a little please? I feel it's derailed a little from the spirit of the thing. @marklawlor's outline was a good one, and it's definitely something people are interested.

That said, @govpack if you're interested in doing a rebuttal, alternative take, or a demo of your results having downloaded and tested on the entire of NPM, I'm sure that would be welcome too. But perhaps don't spoil it all for us beforehand. ;)

tomtomau commented 9 years ago

To get things back on track... +1 Would really appreciate/benefit from the talk, looking forward to it.

govpack commented 9 years ago

+1e6 to the original outline, and i do take your point and i totally agree with getting "things back on track" totally - if i'm commenting at all it means i'm WAY off track, i have other things to do, but i've enjoyed it, so whatever

I will be away early May, and have proposed something else to talk about at a later date, so what does it matter if i post a few testing related notes to this thread, will the internet break? Isn't that the whole point? (i have issues, big deal) i'm absolutely happy that anyone talks about anything they want to. testing is a GREAT added extra!! If you want the zen of a blank page i suggest you try "about:blank" but where's the fun in that

instead why not try https://github.com/banterability/blueshift

npm i blueshift -g

bs=require('blueshift'); console.log('<h1 style="color:'+bs('San Francisco')+';border:25px solid '+bs('Singapore')+';background:'+bs('Brisbane')+'">blueshift</h1>')

Singapore is a leaf, Brisbane is an Olive, San Francisco is a red berry

none of them are blue!! what cities are blue? SkyCity or SunCity - the one Alan Bond wanted to make near Yanchep), nothing is spoiled, it's all good, i'd like to encourage the "@banterability" [what a username!!] of issue threads ~ it is social coding, it is chat ~ and let them get really long if they need too.

yanchep is #94d103 green like a granny smith apple, and it is also the salad bowl for Perth, so what do you know? I left my heart in cuperinto (sounds like a love story) cuperinto is a hole #5b75a5 and also a wonderful shade of blue, the tee shirt was black, the man wearing it was pink, what cities are pink? there's only one true way to find out and that's "testing" - an absolute essential!!! Which is why i don't think there can be enough good things said about it, refer to the above thread. Close [x] the issue for goodness sake, but what if other people wanted to comment (exactly) well let them, it's no big deal.

Jeff long @baterability is from Chicago, blueshift('Chicago') #9cfa1e Chicago is bright green fluorescein

Windy City Colors It's Skyline Green: : TreeHugger www.treehugger.com418 × 239Search by image It's a Chicago tradition to dye the River a bright green on St Patrick's Day. No environmental symbolism intended: just an aquatic parade route decoration that disperses into the suspended solids.

now, i've got to go and hug some trees or something -cheers

ashleygeorgeclarke commented 9 years ago

@govpack Would be good if you could start a new thread for things unrelated to the upcoming unit testing talk

govpack commented 9 years ago

i'd feel better confining things to the one thread, since this one has gone zany out the kazoo already

Could the talk also cover coverage? i've heard istanbul is pretty good?

and pretty nice this time of year: require('blueshift')('Istanbul') //#0ef8f8 it's like cyan or aqua

In package.json.scripts.test we have all these commands has anyone seen a way to make a pie chart out of some keywords and graph them in real time as they come out of the console? there's also the package.json.time fields so we could see the popularity of the various testing libraries over all and over time? -- see above for a BIG list of testing frameworks, see helpful and on topic!! ;-)

Is there an npm switch to tell it to not to install copies of modules that are already present globally?

I haven't seen it, and the way versions lock in possibly not, i'm happy staying with master and having ONLY the latest versions or everything, with a good suite of unit tests to highlight and locate any breaking changes as they arise, otherwise you're going to end up trapped in the past with multiple sub copies of everything.

things like versioneye might help https://www.versioneye.com

"Because software libraries don't update themselves They just become out-dated!"

"Because software libraries are not like iPhone apps They are passive! They don't tell you that they are out-dated!"

"Because software developers are wasting time... looking manually for updates. Save time and money by automating this process."

but that cannot possibly be as good as a good test suite locking in and constantly verifying some required set of functionality, but tests are harder to write than version numbers, and the other thing which would be like transformers or code updaters released with every breaking release,

like go "fix" https://golang.org/cmd/fix/ Fix finds Go programs that use old APIs and rewrites them to use newer ones. After you update to a new Go release, fix helps make the necessary changes

i think that would be the ultimate point of tests, to avoid update pain and the need for version hell

govpack commented 9 years ago

When making a package.json.scripts.test command is good practice to have it install things as well?

I thought it was a bit of a surprise and a bit cheeky to do that, perhaps the talk could give some guidance, because clearly people are all over the place with their scripts.test commands

Search "install" (39 hits in 1 file) C:\TESTPATHS.txt (39 hits) Line 1: tap test/.jstape test/.js test/server/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap testtap test/.jstap test/.jstap testtap testtap test/.jstap testtap test/.jstap test/.jstape test/.jstap test/.jstap test/.jstape test/.jstap test/.jstap test/.jstap test/.jstape test/.jstap test/.jstape test/.jstap test/.jstap test/.jsnode --harmony test/bin/run.js test/.jstap test/.jstape test/.jstap testtap test/.jstap test/.jstap test/.jstape test/.jstap test/.jstap test/.jstape test/.jstape test/.jstap test/.jstape test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstestling .tap test/.jstap test/.jstape test/.jstap test/.jstape test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstape test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstap test/.jstape ... Line 2: 'node test | faucetnode test/testtestlingnode testfaucet test.jsnode testnode testnode test/testnode testnode testtape test/.jsnode testnode testsay sorry && exit 1node testfaucet test/.jstape test/.js | tap-specnode testnode test | faucetnode testnode testnode test | faucetnode test | faucetnode test | faucetnode test -bnode test | faucetnode test | faucetnode test | faucetnode test | faucetnode test | faucetbrowserify test.js | tap-closer | smokestack | tap-spec beefy test.js --opennode test | faucetbeefy test.js --openecho "Error: no test specified" && exit 1beefy test.js --openbrowserify test.js | indexhtmlify | hcatecho "Error: no test specified" && exit 1beefy demo.js:bundle.jsbeefy test.js --opennpm run make:test && cd test/visual && beefy index.js -- -t glslifynode test | faucetecho "Error: no test specified" && exit 1beefy test.js --opennode test | faucetnode test.js | faucetnode testbeefy test.js --open -- -t glslifycd test && beefy index.js --open -- -t ../ -t glslifyecho "Error: ... Line 3: ')" = "Hi Skeet Ulrich. wow.") && echo 'PASS' || ! echo 'FAIL'echo "Error: no test specified" && exit 1echo "Error: no test specified" && exit 1echo "does node-uuid exist? yes? then tests pass." && exit 0./node_modules/.bin/mocha index.spec.js./node_modules/.bin/mocha ./index.spec.jsmocha index.spec.jsecho "Error: no test specified" && exit 1./node_modules/.bin/mocha index.spec.jsecho "Error: no test specified" && exit 1./node_modules/.bin/mocha index.spec.jsecho "looks gooood to me!" && exit 0./node_modules/.bin/mocha index.spec.js./node_modules/vows/bin/vows ./test/test.jsnode test/unit.jsnode test/smoke.jsecho "Error: no test specified" && exit 1echo "Error: no test specified" && exit 1echo "Error: no test specified" && exit 1echo "Error: no test specified" && exit 1echo "Error: no test specified" && exit 1echo "Error: no test specified" && exit 1echo "Error: no test specified" && exit 1echo "Error: no test specified" && exit 1echo "Error: no test specified" && exit 1echo "Error: no test sp... Line 18: node ./install.js && mocha test Line 1914: npm run lint & npm install && ./nodemodules/.bin/mocha --reporter spec --compilers coffee:coffee-script/register spec/.spec.coffee Line 1979: node_modules/component/bin/component-install -d && node_modules/.bin/mocha Line 2192: npm run build && bower install && testem ci --launch PhantomJS Line 2350: npm install nodeunit && nodeunit test.js Line 2434: npm install && cake test Line 2899: npm run install-test-deps && npm run lint && mocha Line 2904: npm run install-test-deps && npm run lint && mocha Line 3007: (npm install mocha && cd test && ../node_modules/mocha/bin/mocha test.js) Line 3691: if [ ! -d bower_components ]; then bower install; fi; ./node_modules/mocha-phantomjs/bin/mocha-phantomjs ./test/index.html Line 3784: npm install && npm install borschik yate && mocha Line 3784: npm install && npm install borschik yate && mocha Line 3785: npm install nanoislands yate && jshint . && jscs . && mocha Line 4665: npm install && grunt default Line 4668: npm install && grunt test Line 5701: npm install --save-dev && ./node_modules/.bin/mocha index.test.js Line 6059: unjip app && cd app && npm install && gulp Line 6061: npm install && gulp test Line 7306: echo "to run demo: npm install beefy -g && beefy test.js" Line 8517: npm install && mocha -R spec -r should Line 8936: npm run postinstall && node test.js Line 10052: DEBUG=autoinstall node test/test.js Line 10452: cd ./test && node ../bin/spaceload install --test && node ./test.js Line 10948: npm install nodemon -g && grunt

or echo "See https://travis-ci.org/lodash/lodash-cli for testing details." what kind of a cop out is that you want me to read some more readme do you? (actually something like that might be better, for you're getting really serious about testing)

NOTICE: If tests fail, please ensure you've set the correct credentials in test/test-server.json

nice

some of the commands seem a bit long, i prefer ones like

mocha grunt grunt test mocha test

or the plain node ones like "scripts": { "test": "node test/runner.js" }

also i spoke to crockford about all those unnecessary double quotes, but he just said why would anyone write json by hand, and that i was silly, I said: hey it's only like one regular expression and they don't have to be there (javascript itself is fine with cleaner object literals) spare the clutter, awkward ~ this is like a frowny face : {

govpack commented 9 years ago

mmmm cake

govpack commented 9 years ago

Also why are people using the scripts.test property for messages like

echo "Error: no test specified" && exit 1

is extremely popular, who/why/what/when did that get added there?

govpack commented 9 years ago

Also, how do i tell if a test has completed or stalled? like the one below

do any of the testing libraries have options for structured output? like isn't this also about automation and data, shouldn't there be more than just read only text? what are the data standards for test based output? are there any major tools that consume/display them, do they often get logged in some way

┌────browserstack-webdriver─────────────────────────────┐ ├── ♫ BrowserStack WebDriver JavaScript bindings with keep alive support ├── ♫ TE:node_modules/mocha/bin/mocha -R list --recursive test

. chrome.Options fromCapabilities should return a new Options instance if none were defined: 0ms . chrome.Options fromCapabilities should return options instance if present: 0ms . chrome.Options fromCapabilities should rebuild options from wire representation: 0ms . chrome.Options fromCapabilities should rebuild options from incomplete wire representation: 0ms . chrome.Options fromCapabilities should extract supported WebDriver capabilities: 0ms . chrome.Options addArguments takes var_args: 0ms . chrome.Options addArguments flattens input arrays: 0ms . chrome.Options addExtensions takes var_args: 0ms . chrome.Options addExtensions flattens input arrays: 0ms . chrome.Options toJSON base64 encodes extensions: 16ms . chrome.Options toCapabilities returns a new capabilities object if one is not provided: 0ms . chrome.Options toCapabilities adds to input capabilities object: 0ms . chrome.Options toCapabilities sets generic driver capabilities: 0ms 1) [chrome] options can start Chrome with custom args

it didn't tell me anything was wrong, but it seemed stalled after this point, 0ms can't be right can it? is that like quantum computing

govpack commented 9 years ago

in some cases the tests are not in npm tar ball but are on github instead making them a little harder to run

govpack commented 9 years ago

in mocha at least one can do a --reporter json|doc|html|markdown or somesuch to have it emit test "units" as documentation

Looking for a module that does this across many test frameworks without having to trawl through the various asts myself?

any ideas for generating documentation from unit tests across many languages, is there a standout project that does this?

-R, --reporter specify the reporter to use

┌────────────insect───────────────────────────────┐ ├── ♫ Bites into your methods so that you know when and how they're called. Simple enough ├── ♫ TE:mocha test/* ├── ♫ CMD:cmd /c mocha C:/ProjectFolder/ --recursive -R json > C:/OUTPUT/insect.txt ├── ♫ WD:mocha

┌───────installfont──────────────────────────────────┐ ├── ♫ Super easy nodejs system font installation

if "installfont" runs cross OS then that's pretty cool !!

tuning in to some javascript testing talks:
•JavaScript Testing Tactics https://www.youtube.com/watch?v=HHcEjAQ46Io •Javascript Testing: The Holy Grail - Adam Hawkins at Reject.js 2012 https://www.youtube.com/watch?v=YdFQ29oK50M

there are going to be as many different opinions about this as there are people using/not using such. (Q) why do testing? (A) to see if it works. so testing is an absolute essential, the whole way thru but if there's an easier way to confirm (A) then stop there. The time sink, the mind shift, of writing more formal unit tests comes at a huge cost, because it shifts away from improving to the code itself, writing new apps, and doing other important things, testing has become a goal unto itself and is a messy confused/confusable business (but the browser based testing/automation is a challenging thing with many tools/methods in the works, so solving in more/better ways is totally worthwhile). As i see it, a working APP or API is THE test, gaining some measure of end user satisfaction [time to result, navigability, usage rates] and an automated feedback loop for that, would be far more valuable. I'm happy with other people writing unit tests, because it gives another view into what some module is doing.

Roy Osherove who spent three years writing "the art of unit testing" and then went to a 2nd edition, because he felt some of what he said in the 1st book were wrong, and points out many of the problems as he sees them in his talk:

•Roy Osherove - "JS Unit Testing Good Practices and Horrible Mistakes" https://www.youtube.com/watch?v=iP0Vl-vU3XM

Roy also mentions that the jquery test suite (at that time) takes 7 minutes to run, requires a running php server for all tests to pass and specifies the number of asserts to be specified up front so that it can tell if the process hangs (which was one of my dozen earlier questions) but that number can get out of sync, why a testing framework wouldn't have some way of counting them i wouldn't know.

I would be more interested in having something like the iMacros or selenium test recorder working, and something in node that watches all method calls (along with the actual data being passed) to generate a set of tests automatically. Just at their OED definitions: fakes, mocks, spies, stubs sound like really bad words, and ought to be avoided if at all possible.

The reason there are so many testing frameworks is that people don't like them, and the learning curve is so high, that often it's easier to write a new one than to pick up an existing one (it's like picking up a cactus)

marklawlor commented 9 years ago

I've been gone for a couple of days and this issued seemed to gone...off topic.

I'm happy for people to express different opinions, but I think we can all agree this issue is no longer constructive and @govpack hasn't approached the discussion in a friendly manner.

If I was a new developer volunteering for a talk, I'd probably be scared off, by both the replies and the lack of moderation.

@ashleygeorgeclarke @kevdesign @MauriceButler Can someone please close this issue and I'll create a new issue to track the talk.

govpack commented 9 years ago

mocha -R nyan test/fastsync_test.js

22 ------------,------, 0 ------------| //\ 0 ------------^|_( ^ .^) ------------ "" ""

22 passing (3s)

govpack commented 9 years ago

┌────────────────lolapi──────────────────────────────┐ ├── ♫ Wrapper of the official League of Legends public API ├── ♫ TE:mocha -t 5000 ├── ♫ CMD:cmd /c mocha C:/../lolapi/ --recursive -R Markdown > C:/YoYo/lolapi.md ├── ♫ WD:mocha

C:\Z\X\114\B\2\N22230\Ax\1\test\config.js:4 throw new Error("Please set an API key in test/config.js or an environment v

wondering what to do about all the modules that who's tests fail

because of the missing 'windows' object, is there some node module that will patch any failing tests thru to a browser context?

govpack commented 9 years ago

mocha -h -t, --timeout set test-case timeout in milliseconds [2000]

ashleygeorgeclarke commented 9 years ago

thanks @marklawlor

colingourlay commented 9 years ago

@govpack ummmmm, Josh...

You wouldn't happen to have anything to do with what @seldo is talking about on Twitter, would you?

https://twitter.com/seldo/status/593582059349610496 https://twitter.com/seldo/status/593583506954956800

seldo commented 9 years ago

Unless @govpack is downloading every single version of every single package several dozen times each from a fleet of amazon boxes, it's unlikely to be them.

colingourlay commented 9 years ago

@seldo, probably not, by the sounds of the scale of the operation, but I've learned to never underestimate @govpack's tenacity

BrisJS / meetups

Suggestion for unit testing #45

Week 1:

Week 2 - Testing workflows for prototyping/small libraries:

Week 3 - Testing workflows for larger applications

});

the readme is about as helpful (like everything is there except the bit you'd want most)

parsetition

Installation

Example

API

License

my unit has a leaky ceiling :( how can this help?

i wish the legacy of those old java heads was that we didn't have to repeat that stuff

i looked them all up on github and they are all shockingly unproductive!!!

"0/0 tests ran successfully, everything passed"

=== in 0ms

=== SUCCESSFUL

Singapore is a leaf, Brisbane is an Olive, San Francisco is a red berry

Could the talk also cover coverage? i've heard istanbul is pretty good?

Is there an npm switch to tell it to not to install copies of modules that are already present globally?

When making a package.json.scripts.test command is good practice to have it install things as well?

NOTICE: If tests fail, please ensure you've set the correct credentials in test/test-server.json

Also why are people using the scripts.test property for messages like

echo "Error: no test specified" && exit 1

is extremely popular, who/why/what/when did that get added there?

any ideas for generating documentation from unit tests across many languages, is there a standout project that does this?

wondering what to do about all the modules that who's tests fail