search

danShumway / vAnalyze.js

A middleware script that seeks to allow functions in local javascript to be automatically wrapped in custom code wrappers. These can then be used to aid profiling/error checking/code understanding.
GNU General Public License v2.0
4 stars 1 forks source link

Add test framework #10

Closed PxlBuzzard closed 9 years ago

PxlBuzzard commented 9 years ago

Mocha or QUnit are both good options. You can set up Travis to automatically run them whenever you push as well.

danShumway commented 9 years ago

I've been recently getting less and less enamored by the idea of sever-based tests over local tests, because once I push code, I can't do anything about it other than make a new commit. I'm in the process of setting up grunt to get a good build solution though, and part of that will involve QUnit.

There are some thoughts to be had there about whether or not some of that can merge with the examples folder, and whether or not that can be set up in an elegant way to include test outputs in each commit so I'm not officially including this in the initial milestone, but there's a non-trivial chance I'll just do it anyway.

Officially though, this is on hold.

PxlBuzzard commented 9 years ago

Travis isn't necessarily for you, though it is still a good fallback/confirmation that it works on something that isn't your machine. It becomes far more valuable when other people submit a PR and you have verification that tests pass without needing to merge their changes onto your machine and run them yourself.

EDIT: It is also very useful to let other people know that if they download the code, it should work. For example, and not to toot my own horn, but seeing a "Build Passing" and "93% Coverage" in nunjucks-brunch offers new users a quick message that the code is stable and tested.

danShumway commented 9 years ago

Note to self then to keep it at least somewhat in mind when setting up grunt, because if I'm in a situation where I need to be monitoring other people's contributions, I'll want to also be doing combining, minifying, and any doc updating through Travis as well. I don't think there's a world where I trust contributors with either some of that or all of it.

Again though, this feels to me like a problem that can wait a bit, at the least until I have a finalized API that I can say with confidence isn't going to change for a while. At the moment, this project is too young for me to start talking about expected behaviors on this scale or for me to be accepting outside contributions for anything other than the smallest modifications. It is on the list, but I won't make promises about it being this milestone.

danShumway commented 9 years ago

Added basic QUnit support in most recent build - I'll use this as an excuse to finalize some of the API as I build out tests.

Note that this does not mean the project is stable or production ready. It's safe to assume that any behaviors not being tested have not been finalized, and until official documentation is pushed up, that even tested behaviors may change (although this is much less likely).

I'm leaving this issue open until I decide on whether or not I want to do anything with Travis, and how I want to handle the rest of the build process (generating log files from tests, docs, etc.)

danShumway commented 9 years ago

Will likely be doing something similar to Yuidocs for documentation since it links back to the source code for methods, and I find that useful when using libraries. Would like something better, since Yuidocs doesn't allow searching via methods (at least not very well last time I checked). I really like the http://devdocs.io/ interface, I've been looking around for something similar.

I won't be setting up anything like Travis until after an initial release - when I do, I'll likely be setting it up for vetting submitted code more than anything else. If someone makes a pull request, I want to look through their code locally and run tests on my machine.

What I am interested on for public facing stuff is getting qUnit to show up on a github page for this with whatever the most recent binary is. This lets you basically run your own tests on the code you're downloading/see what they all are. This also serves the double purpose of making my documentation life easier, since I've been using my qUnit tests as the official spec up til now - qUnit tests are guarantees about how the program will act, any other documentation is just easier parsed directions on how to make it act and tips on making it act well.