I’m pleased to announce TestR (was test-loop) which now follows the
UNIX philosophy of small text-based programs that do one thing well.
The complete release notes and details are below. Happy testing.
TestR - Continuous testing tool for Ruby
https://github.com/sunaku/testr#readme
What is it?
TestR is a continuous testing tool for Ruby that efficiently
detects and tests changes in your Ruby application & test suite:
Absorbs test execution overhead into the master Ruby process.
Forks to run your test files in parallel and without overhead.
Avoids running unchanged tests inside changed test files.
What is new?
Incompatible changes:
Renamed this project and its resources from test-loop to TestR.
Renamed the reabsorb_file_globs configuration parameter to reabsorb_file_greps. It now contains regular expressions.
Renamed the test_file_matchers configuration parameter to test_file_globbers. Its keys are now regular expressions.
Renamed the test_name_parser configuration parameter to test_name_extractor.
Renamed the max_concurrent_tests configuration parameter to max_forked_workers.
Renamed the before_each_test configuration parameter to after_fork_hooks. Its function parameters have also changed.
Removed the delay_per_iteration, after_each_test configuration
parameters.
Removed the test/loop/notify and test-loop/coco libraries.
New features:
The file system is no longer polled to detect modified files.
Instead, the file system is monitored for file modification events
in a portable and efficient manner using the Guard library.
The number of processors on your system is automatically detected
for the max_forked_workers configuration parameter.
Added overhead_load_paths, all_test_file_globs, and before_fork_hooks configuration parameters.
Added ability to re-run passed and failed tests in the testr
script.
Housekeeping:
The monolithic test-loop script has been replaced by several
smaller ones that communicate with each other using single-line
JSON messages via their standard input & output streams. See
“Architecture” in README for details.
Now using Bundler to manage development dependencies and gem
packaging.
On Oct 9, 2011, at 17:09 , Suraj N. Kurapati wrote:
I’m pleased to announce TestR (was test-loop) which now follows the
UNIX philosophy of small text-based programs that do one thing well.
The complete release notes and details are below. Happy testing.
Version 0.0.1 (2010-10-10) – your project is now 1 year old exactly…
happy birthday!
You’re a vocal proponent of semver and you just hit version 14 which
means you’re doing 1 major/backwards-incompatible release every 1.1667
months. Now that this project is a year old, can you shed any
perspective on any of that and how well it has worked?
On Oct 9, 2011, at 17:09 , Suraj N. Kurapati wrote:
I’m pleased to announce TestR (was test-loop)
Version 0.0.1 (2010-10-10) – your project is now 1 year old
exactly… happy birthday!
You’re a vocal proponent of semver and you just hit version 14
which means you’re doing 1 major/backwards-incompatible release
every 1.1667 months. Now that this project is a year old, can you
shed any perspective on any of that and how well it has worked?
I works very well for me because my release numbering is consistent
(per RRV and SemVer) and people can rely on that by specifying tilde
constraints like “~> 14” when installing or depending on my gems.
Although I’m a perfectionist, I don’t aspire to ever reach a golden
“1.0” release and stop / slow down there, because there’s always
room for improvement in my view and bit-rot is all too pervasive.
For that reason, I follow RRV mechanically and don’t bother with the
“unpleasantness” of making frequent major releases. If people want
to continue using the old versions, they are most welcome to do so.
In the case of this particular gem, it is more of a tool than a
library so I really only bump the major version when there are
incompatible changes in the tool’s (Ruby) configuration file.
I hope this has answered your question. Let me know if otherwise.
On Oct 9, 2011, at 17:09 , Suraj N. Kurapati wrote:
I’m pleased to announce TestR (was test-loop)
Version 0.0.1 (2010-10-10) – your project is now 1 year old
exactly… happy birthday!
You’re a vocal proponent of semver and you just hit version 14
which means you’re doing 1 major/backwards-incompatible release
every 1.1667 months. Now that this project is a year old, can you
shed any perspective on any of that and how well it has worked?
It works very well for me because my release numbering is consistent
(per RRV and SemVer) and people can rely on that by specifying tilde
constraints like “~> 14” when installing or depending on my gems.
Although I’m a perfectionist, I don’t aspire to ever reach a golden
“1.0” release and stop / slow down there, because there’s always
room for improvement in my view and bit-rot is all too pervasive.
For that reason, I follow RRV mechanically and don’t bother with the
“unpleasantness” of making frequent major releases. If people want
to continue using the old versions, they are most welcome to do so.
In the case of this particular gem, it is more of a tool than a
library so I really only bump the major version when there are
incompatible changes in the tool’s (Ruby) configuration file.
I hope this has answered your question. Let me know if otherwise.
merges with “patch”) for releases lacking significant API changes. A
forth number can be used for mid-development “build” or pre-releases.
For the same reason you start a question and end it with a period or use
“forth” instead of “fourth”. Likewise asking a question like this of
someone who is diametrically opposed to your design and process ideas.
concept of the project’s version. The second number is then “major”,
for releases with API changes, and the third “minor” (and basically
merges with “patch”) for releases lacking significant API changes. A
forth number can be used for mid-development “build” or pre-releases.
For the same reason you start a question and end it with a period or use “forth”
instead of “fourth”. Likewise asking a question like this of someone who is
diametrically opposed to your design and process ideas.
It wasn’t a question. And I never could suffer a man who couldn’t
spell a word more than one way.
As for the rest, I dare say my designs entail that you should most
definitely stick to your opposition.
Version 0.0.1 (2010-10-10) – your project is now 1 year old exactly… happy
birthday!
You’re a vocal proponent of semver and you just hit version 14 which means
you’re doing 1 major/backwards-incompatible release every 1.1667 months. Now that
this project is a year old, can you shed any perspective on any of that and how
well it has worked?
Why I have found myself drifting toward the idea of a “right shifted”
semiver standard, where the first number is instead a subjective
concept of the project’s version. The second number is then “major”,
for releases with API changes, and the third “minor” (and basically
merges with “patch”) for releases lacking significant API changes. A
forth number can be used for mid-development “build” or pre-releases.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.