Forum: Ruby ZenTest 3.0.0 Released

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ryan D. (Guest)
on 2006-03-07 02:26
(Received via mailing list)
ZenTest version 3.0.0 has been released!

   http://www.zenspider.com/ZSS/Products/ZenTest/

== DESCRIPTION

ZenTest provides 3 different tools: zentest, unit_diff, and autotest.

ZenTest scans your target and unit-test code and writes your missing
code based on simple naming rules, enabling XP at a much quicker
pace. ZenTest only works with Ruby and Test::Unit.

unit_diff is a command-line filter to diff expected results from
actual results and allow you to quickly see exactly what is wrong.

autotest is a continous testing facility meant to be used during
development. As soon as you save a file, autotest will run the
corresponding dependent tests.

There are two strategies intended for ZenTest: test conformance
auditing and rapid XP.

For auditing, ZenTest provides an excellent means of finding methods
that have slipped through the testing process. I've run it against my
own software and found I missed a lot in a well tested
package. Writing those tests found 4 bugs I had no idea existed.

ZenTest can also be used to evaluate generated code and execute your
tests, allowing for very rapid development of both tests and
implementation.

== FEATURES/PROBLEMS

* Scans your ruby code and tests and generates missing methods for you.
* Includes a very helpful filter for Test::Unit output called unit_diff.
* Continually and intelligently test only those files you change with
autotest.
* Includes a LinuxJournal article on testing with ZenTest written by
Pat Eyler.

   http://www.zenspider.com/ZSS/Products/ZenTest/

Changes:

+ 2 major enhancements
	+ Added autotest and rails_autotest. YAY for continous testing!
	+ Repackaged and gemified. YAY for gemification!
+ 3 minor enhancements
	+ Added non-mappable tests starting with test_integration_.
	+ Lots of code and test refactoring and cleanup.
	+ Massive improvement on unit tests.
+ 3 bug fixes
	+ Cleaned up class method inheritence. Esp relevant for rails testing.
	+ Finally fixed the unit_diff parse bug!
	+ Fixed improper counting of errors if a class was missing, should
be 1 + missing methods.

   http://www.zenspider.com/ZSS/Products/ZenTest/
Wilson B. (Guest)
on 2006-03-07 03:11
(Received via mailing list)
On 3/6/06, Ryan D. <removed_email_address@domain.invalid> wrote:
> code based on simple naming rules, enabling XP at a much quicker
> pace. ZenTest only works with Ruby and Test::Unit.
>
> unit_diff is a command-line filter to diff expected results from
> actual results and allow you to quickly see exactly what is wrong.
>
> autotest is a continous testing facility meant to be used during
> development. As soon as you save a file, autotest will run the
> corresponding dependent tests.
>

This is awesome. Thanks, Ryan!
Bil K. (Guest)
on 2006-03-07 16:49
(Received via mailing list)
Ryan D. wrote:
>
> ZenTest version 3.0.0 has been released!

Excellent news.

> ZenTest scans your target and unit-test code and writes your missing
> code based on simple naming rules, enabling XP at a much quicker
> pace. ZenTest only works with Ruby and Test::Unit.

This has always sounded scary to me as written because
it goes against the behavior notion best described by
Astels: http://blog.daveastels.com/?p=53

> unit_diff is a command-line filter to diff expected results from
> actual results and allow you to quickly see exactly what is wrong.

I've always thought that this should be folded into test/unit
as an option.

Ryan/Nathaniel, what say you?

Later,
Eric H. (Guest)
on 2006-03-08 01:02
(Received via mailing list)
On Mar 7, 2006, at 6:48 AM, Bil K. wrote:

> it goes against the behavior notion best described by
> Astels: http://blog.daveastels.com/?p=53

On the "What Then?" slide I see this:

* small, focused pieces of behaviour
* sub-method
* an interesting method will have several facets to its behaviour

For me this throws up a big flag that says the code isn't factored
properly.  A method should be a small, focused piece of behavior
without several facets to its behavior.  If a method does more than
one thing it should be broken into methods that each do one thing.

When you write your code in small units of behavior mapped to methods
then ZenTest is a perfect match.  If you have poorly factored code
and big methods with many outputs and inputs test coverage is very
difficult to judge because you can't easily track what goes on inside
your methods and match it up to test cases.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Bil K. (Guest)
on 2006-03-09 00:44
(Received via mailing list)
Eric H. wrote:
> thing it should be broken into methods that each do one thing.
Excellent point.  So, I'll have to attack on another
front. :)

Automatically creating tests after the methods misses
the design benefits and the other economies of test-driven
design -- see Beck's draft on /When to Test/,

  http://tinyurl.com/n2czh

Note: it's in the members-only file section of the
Yahoo extremeprogramming group.

Later,
This topic is locked and can not be replied to.