tlevine/urchin
1
0
Fork 0
Code Issues 5 Pull Requests 1 Packages Projects Releases Wiki Activity

move more todo to history

Browse Source
This commit is contained in:
Thomas Levine 2016-02-29 03:31:10 +00:00
parent c47cdf6bc8
commit c97d212485
2 changed files with 23 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
HISTORY
View File

@ -128,6 +128,29 @@ strategies if your setup file gets complicated.
2. Export a path in your setup file, rewrite your setup file as a shell
program, and put the rewritten file in your path.
### Run on a file
Previously you could run urchin only on a directory (and, in turn, all files
in that directory). Now you can run Urchin on a single file.
This occurred to me when I wanted to run
urchin test/fast/Unit\ tests/nvm_ls_current
on the nvm tests. I wound up running this instead.
urchin test/fast/Unit\ tests/ | grep nvm_ls_current
But now I don't have to; the first of these commands will work.
When you run urchin on a file, the test suite root is determined (as with any
other Urchin call), and the test suite is recursively descended. Setup and
teardown files are sourced, and everything but the specified test file is
otherwise ignored.
If you don't explicitly specify the Urchin root with a .urchin file, we
consider the test suite root directory to be the parent of the file that
you ran Urchin on.
Version 0.0.6
---------------------

29
TODO
View File

@ -80,29 +80,6 @@ This is as far as I have gotten with contemplating license changes. For now
we're sticking with the original MIT-style license, but it's easy to change
licenses later.
Run on a file
----------------
Presently you can run urchin only on a directory.
It would be neat if you could run it on a file as well.
This occurred to me when I wanted to run
urchin test/fast/Unit\ tests/nvm_ls_current
on the nvm tests. I wound up running this instead.
urchin test/fast/Unit\ tests/ | grep nvm_ls_current
The Molly guard would be assessed, and the corresponding setup, setup_dir,
teardown, and teardown_dir files would be run in the appropriate order.
In order to know how far up the tree to evaluate the setup, &c. files,
I think it would make sense to require that a ".urchin" file be placed in the
root of the tests. Urchin would keep going up until it sees this file, and it
would evaluate the appropriate setup, &c. files from there down to the
particular test file of interest. We would also use this for testing
directtories more correctly.
Running automated tasks
-------------------------
Urchin might be appropriate for if you have lots of tasks that you want to run
@ -114,9 +91,3 @@ this sort of thing.
* Optionally kill tests/jobs after a specific timeout threshold
* Send output of different tests/jobs to different files for each file
descriptor (STDOUT, STDERR)
sorting
-------
How do sort properly?
printf '- a\n-- a\n--- a\n- b\n-- b\n--- b\n'|sor