# What to cover for a TDD and BDD toolkit/course?

**URL:** <https://www.ruby-forum.com/t/what-to-cover-for-a-tdd-and-bdd-toolkit-course/136561>\
**Category:** Ruby\
**Created:** [May 3, 2008, 6:12pm UTC](https://www.ruby-forum.com/t/what-to-cover-for-a-tdd-and-bdd-toolkit-course/136561 "2008-05-03T18:12:45Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Phillip\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ab992/32.png) [@Phillip\_G](https://www.ruby-forum.com/u/Phillip_G)\
**Post date:** [May 3, 2008, 6:12pm UTC](https://www.ruby-forum.com/t/what-to-cover-for-a-tdd-and-bdd-toolkit-course/136561/1 "2008-05-03T18:12:45Z")

</div>

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1

I’ve volunteered to create a new course for Satish T.'s  
[rubylearning.org](http://rubylearning.org).

I want to cover rather basic stuff in regard to TDD and BDD, and the  
tools tying into Test/Behavior Driven Development.

I plan on covering Test::Unit and RSpec at least, in a (thereabouts) 8  
week course.

What do you folks think I should include?

I want to cover some external tools, too (a bit of Rake, a bit of RCov,  
maybe Heckle).

There are no plans on covering Rails or other framework specific  
additions, neither tools that are system specific (nothing that is  
Windows or \*NIX only).

I want to cover the Test::Unit library in depth (at least all the types  
of assertions, and organizing tests in suits, naming conventions, etc),  
and at least touch on RSpec.

So, the question to you folks is: What tools would you recommend to  
include in this?

The audience are nubys to Ruby at least, maybe even TDD/BDD.

* * *

Phillip G.  
Twitter: [twitter.com/cynicalryan](http://twitter.com/cynicalryan)  
Blog: [http://justarubyist.blogspot.com](http://justarubyist.blogspot.com)

~ “Mom and dad say I should make my life an example of the principles  
I  
~ believe in. But every time I do, they tell me to stop it.”  
~ — Calvin

-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1.4.8 (MingW32)  
Comment: Using GnuPG with Mozilla - [http://enigmail.mozdev.org](http://enigmail.mozdev.org)

iEYEARECAAYFAkgcjroACgkQbtAgaoJTgL9L/wCdEJvit6LDhDYyVjBSmeVamKPK  
gpYAoKMdNL7izJtQkPPsg/AJ3EfE1nQQ  
=32id  
-----END PGP SIGNATURE-----

---

<div class="post-metadata">

**Author:** ![Phillip\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ab992/32.png) [@Phillip\_G](https://www.ruby-forum.com/u/Phillip_G)\
**Post date:** [May 4, 2008, 4:07am UTC](https://www.ruby-forum.com/t/what-to-cover-for-a-tdd-and-bdd-toolkit-course/136561/2 "2008-05-04T04:07:33Z")

</div>

Something about ZenTest / autotest? I’ve never had autotest set-up  
myself, but it sounded rather useful. I don’t think it’s Rails  
specific.

---

<div class="post-metadata">

**Author:** ![Phillip\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ab992/32.png) [@Phillip\_G](https://www.ruby-forum.com/u/Phillip_G)\
**Post date:** [May 5, 2008, 1:47pm UTC](https://www.ruby-forum.com/t/what-to-cover-for-a-tdd-and-bdd-toolkit-course/136561/3 "2008-05-05T13:47:45Z")

</div>

On Sat, May 3, 2008 at 6:11 PM, Phillip G.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> week course.
> 
> What do you folks think I should include?

What I see as important - more important than training people in the  
specific list of assertions available today - include:

How to organize and maintain unit tests over time.

How to structure your code to work well with Unit testing

How to test in icky situations, including

- How to test with databases
- How to test GUIs
- How to test web UIs (Selenium or some web driver)

I would probably also include a brief talk about acceptance testing,  
possibly also some work on performance testing.

Another semi-optional part: How to add invariants checks and how they  
differ from and to what degree they cover the same area as unit tests.

That’s what my curriculum would look like at first draft - much more  
focused on the big picture of how to live with unit tests, and less  
focused on the small details of how to use the particular API - just  
enough API to get people started.

Eivind.
