On Sat, Apr 18, 2009 at 8:18 AM, Ram <[email protected]> wrote: > > <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 don't think that this is a good idea at all. Definitely start testing immediately but I wouldn't rewrite the app at all. For every bug fix and change, make sure you write tests for the functionality you are working on (in a TDD/BDD way - before changing the code.) Jim Wierich did an excellend talk at Scotland on Rails about Comment Driven Development which, if I can summarise it accurately, is as follows: When changing/bug fixing existing code 1. Comment out the code in question 2. Write tests on how the code should work 3. Only uncomment the code that makes the test pass Repeat 2 & 3 until you have the code completely covered in tests 4. Write a test for the new feature/bug fix (if not already fixed by now) 5. Write the new feature/bug fix Done! If you do this whenever you work on existing code, you'll grow the test coverage of the app over time. > > - 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 still wouldn't use fixtures. I work with factories because then you can put together the complex associations and data needed for just the question at hand. I have recently started creating a test library for very complex applications that will build up a complex set of data via TestData.load_data type calls. I do this so that I only load up the data for those areas where the tests need them and not on every test. > > - 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) Cucumber is not just for client documentation but does end-to-end or full-stack testing which is useful for getting as-close-as-the-client-experience testing > 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? This I covered above. Start your testing with the new features (Another reason not to re-write) Include all the testing you want on a per-feature basis. > > my 2 cents worth.. i personally like the feel autotest gives. > especially for TDD. but hey.. no experience. only tryouts and > screencasts. I have no problem with autotest running on large projects as I find that when it starts running the full suite, I'm busy writing the next test/spec. When working with a failing test, autotest only re-runs the failing test anyway. Andrew Timberlake http://ramblingsonrails.com http://www.linkedin.com/in/andrewtimberlake "I have never let my schooling interfere with my education" - Mark Twain --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
