<Yikes!> ok that was some intense stuff. I dint understand a lot of stuff going around because, as established before, I dont have experience writing tests. But the following are the things Im taking out of this discussion.
- jump in the dirt. Do TDD for your existing app by starting all over again if you have to. Thats the only way to go (?) / thats the best way to go to become a better programmer (?) - i dont *absolutely* need any external tools besides test::unit. I probably would use the right tools if i ever felt the need for them in the first place - use fixtures when I have to test something that uses complex associations between models. especially when the alternative is to spend a lot of time and brain on mocking/stubbing them instead. (I have to mention I dont know the difference/similarities/functions of mocking and stubbing completely) - i dont have any client documentation to show for these tests. theyre only for the sake of testing my code itself. So ill skip over RSpec and Cucumber (until i feel a need for them) - test code keeps evolving. I need to optimize test code as much (or more ?) as i optimize dev code. and tests breaking out of nowhere will be a way of life (?) i am going to be adding features to the app in between too. anything I have to keep in mind while doing that? when do I start on integration and functional tests? Also, any good articles that could help me gain some perspective on the task i have ahead of me? my 2 cents worth.. i personally like the feel autotest gives. especially for TDD. but hey.. no experience. only tryouts and screencasts. Please DO let me know if I have taken away the right things from here *to get started* with writing tests for my existing app. I hope this discussion goes further and provides insights for many more in my place. Thanks Fernando, Marnen, Phlip, Brandon and Hans :) On Apr 18, 1:17 am, "Phlip" <[email protected]> wrote: > Marnen Laibow-Koser wrote: > >> We are not writing QA "Unit Tests" - the kind CPU manufacturers write. > >> They need > >> pure isolation between units, so when a test fails it only implicates > >> one unit. > > > Aren't we, though? What's the point of a test that doesn't tell you > > what failed? > > Under TDD, the element that failed must be among your recent edits. > Therefor, tests are free to cross-polinate any of your modules together... > > >> No. I meant "expensive setup is a design smell". > > > Then I guess I shouldn't be using Rails. I don't know how to test > > anything based on ActiveRecord without reasonably expensive (in dev > > time, anyway) setup. What am I missing? > > I don't mean this is expensive... > > foo = foos(:my_foo_fixture) > > ...I mean a zillion lines of pure clutter, building object after object and > glueing them all together just the right way. That's expensive. > > >> Fixtures are among the systems that keep object models easy to whip out > >> and use. > > > Why not mock/stub model objects instead? I don't see a single benefit > > from using fixtures, except that the setup expense is shifted from the > > developer (lots of mocks) to the computer (excessive DB access resulting > > in *slow* tests -- see Asynchronous Unit Testing antipattern). Is there > > a third way that I'm missing? > > Better the computer is slow than the developer. That's orders of magnitude > difference there. > > If your tests get too slow, install CruiseControl.rb for a build server. > > -- > Phlip --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
