ActiveTest::Redesign < ActiveTest::Examination
Posted by Mathew Abonyi Tue, 02 Jan 2007 14:55:27 GMT
The following is taken straight from the first two sections of the ActiveTest Redesign Draft. Feel free to comment, ask for features, steer me away from the unnecessary or just say you’re interested.
1.0: ADDRESSING A NEED
This section takes a cursory look at the evolution of ActiveTest.
1.1: The Original Premise
I originally started writing ActiveTest to address problems I had with Test::Unit. It lacked the following for my projects:
- inheritance
- modularity (adding)
- flexible (redefining)
- granular verbosity
- observing
- BDD interface
The most annoying omissions were the first two. I felt that no matter how much documenting my tests were doing, I hated breaking with the habit of not repeating myself. There are simply times when different parts of an application share a common interface or set of functions. That’s all there needs to be said in the tests.
1.2: Problems with ActiveTest 0.1.0
The first beta of ActiveTest was a flop; it was too specific to Rails, especially controllers, and used too many metaprogramming techniques. Consequently, it created doubt about the failures in test cases—were they ActiveTest or real? It mildly discouraged TDD and, as seen in my small series of articles on the mistakes I’ve made, there was too much focus on the One-Liner™.
1.3: Current State of Need
From what I can tell, there are three related schools of thought about testing which have members in the Ruby community: Test Driven Development, Behaviour Driven Development and Story Driven Development. The Agile and XP groups of developers select whichever according to taste. ActiveTest can easily cater to all schools and groups.
Looking at Test::Unit and comparing it to other projects, it is apparent that Rubyists are being left high and dry. Concessions have come in the form of ZenTest for automation, RSpec for BDD, RFuzz for fuzzing, Mocha for mocking, and rcov for coverage. Each of them (except RSpec) are forced to extend an inherently closed model, Test::Unit::TestCase, and the arcane classes which drive it.
2.0: APPROACHING THE REDESIGN
This section explains the purpose and approach for the new ActiveTest framework.
2.1: Purpose
The new ActiveTest is to provide an advanced, backward-compatible replacement for Test::Unit. By this design, it is compatible with many projects already extending Test::Unit, allowing for quick uptake and usage. It is also to be at the forefront of testing theories and advanced testing techniques both within and outside the Ruby community. Ultimately, it’s purpose is to make developers in all other languages very, very jealous.
2.2: Summary
ActiveTest must change from being a Rails plugin to a gem. It must be compatible with other gems and plugins within the Ruby community or, if compatibility is too complicated, incorporate their ideas with due credit. It must take head-on the latest in BDD and SDD styles. It must reuse as much of its old code to this purpose as possible. Finally, it must draw on projects in other languages, most notably Java and Python, to make use of the latest developments.
2.3: Influenctial Ruby projects
- Test::Unit
- ZenTest (especially autotest and Rails View testing)
- Mocha
- RSpec
- RFuzz
- rcov
- Systir
- Rails Fixtures
2.4: Influential projects in other languages
- Testoob (Python)
- JUnit (Java)
- JUnitPerf (Java)
- GroboUtils (Java)
- SimpleTest (PHP)
- TAP (Perl)
- Test::Harness (Perl)
- Test::More (Perl)
2.5: Objectives
The following features from Test::Unit:
- assertions
- setup & teardown
- interfaces: Console, Fox, GTK, GTK2, TK
- auto-running
- filtering
- backtrace
- text report
- unit tests
The following features from Ruby projects are compatible:
- mocking and stubbing (through Mocha)
- fuzzing (through RFuzz)
- coverage reports (through rcov)
The following features incorporated from other projects:
- data fixtures (from ActiveRecord)
- automation (from ZenTest)
- colorized output (from ZenTest & Testoob)
- granular test selection (from Testoob)
- different report formats (from Testoob)
- test threading (from Testoob & GroboUtils)
- Test Anything Protocol (from TAP, Test::Harness & Test::More)
The following features are specific to ActiveTest:
- co-existence of TDD, BDD & SDD testing styles
- inheritance
- test type variety: unit, integration, system, performance
- granular verbosity (backtrace, debug flags)
- interface: Web/AJAX
