@Marnen, Thanks for the responses to all my concerns. And I will take your advice and give RSpec a go too. It definitely is more appealing to the eyes at least on the test method name level (which is how much i know of RSpec +/ test::unit :) )
> Huh? I meant that once i get into writing tests, ill probably know what tools i need if at all i need them. @Fernando, good point well made :) ... I have it installed anyway so Ill go along with it until it starts getting in my way :) @Andrew, >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. That is sweet music to my lazy ears :D. The whole reason ive conveniently ignored writing tests for so long is because its daunting. Rewriting the whole app and doing it the TDD way makes it even more daunting! I must say though that I realize rewriting with TDD is probably gonna do more good than covering my code with tests now. It will make me revisit my app and clarify requirements and functionality and help me understand my app itself a whole lot better overall. But for now, I think im gonna go with writing tests bitwise, covering existing code. If i feel insecure about it at some point, maybe ill rewrite with TDD to give the app a more solid foundation. Ive spent months on this app and rewriting with TDD is just too much added time investment. The Comment Driven Development part is very close to my situation right now. Its an approach that I probably wouldve taken naturally out of necessity rather than in order to follow a technique. :) Thanks a lot for mentioning that. I will look it up in detail. >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 That is actually a good point. But when do I start writing full stack tests? or integration and functional tests too for that matter? Does one always start writing tests with unit tests and work through functional, integration and then full-stack-tests? Isnt that like going from backend to frontend? Would that be the right approach for ANY kind of application? Even if its largely user centric and has got very little magic going on in the models? On Apr 18, 12:35 pm, Andrew Timberlake <[email protected]> wrote: > 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 > Timberlakehttp://ramblingsonrails.comhttp://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 -~----------~----~----~----~------~----~------~--~---
