Phlip wrote:
> Marnen Laibow-Koser wrote:
> 
>>> Despite Rails being the only Web platform designed for TDD, 
>> 
>> Really?  I have the impression that there are others...if nothing else, 
>> some of the Railsy PHP frameworks have copied this feature.
> 
> designed for - not copied on.

Copying a feature in the design phase is still designing it in.  Or were 
you going to say that Ruby wasn't really designed for most of its cool 
features because they were copied from Smalltalk and Lisp? :)

> 
>>> Most importantly, tests should run instantly. 
>> 
>> In most cases, mine do.  The exceptions are those which use regexps or 
>> DOM wizardry for parsing HTML.  I suspect Oniguruma might help here, but 
>> I haven't tried it.
> 
> Rails??

Huh?  Oniguruma is what I haven't tried.

> 
>> RSpec + autotest + out-of-the-box test scripts + any editor you like. 
>> Done.
> 
> When the tests fail, what button do you type to navigate instantly to 
> the test
> failure?

Cmd-Tab.  The test failure is usually where I was last editing. :)

Seriously, you're asking the wrong person.  I don't really care that 
much about that level of editor integration.  If you do, I believe there 
is a TextMate bundle that will do what you want, but you will get better 
answers from others on this list.

[...]
> We do not build a new CPU with new libraries and Ruby installation 
> between each
> test run. 

No, because we can guarantee that those bits won't be changed in a 
typical app.  We cannot guarantee that about the DB, can we?

I *would* want a new Ruby installation for each test run if I thought my 
code were likely to modify the system Ruby installation as it ran.

> All test isolation is a trade-off of some kind.

Sure.

> 
>> Jay Fields has posted some stuff on his blog about how to make Rails 
>> unit tests not touch the DB, but I don't really see much need to do 
>> that.
> 
> Thanks - that's the next thing I was going to ... rail at. Some 
> consultants who
> teach TDD use a mind-trick to motivate their newbs to decouple their 
> code. In a
> big-iron environment where database _migrations_ are expensive, until 
> you pay
> that down, you can get a slight benefit to unit tests that reach into 
> code that
> decouples from the database.
> 
> We should do that too. 
[...]

Do what?  You mentioned several things, and I'm not sure which one 
you're referring to.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to