From: Stefan Schmiedl Date: 2001-11-19T02:37:17+09:00 Subject: [ruby-talk:25770] Re: rubyUnit, et. al. Albert Wagner (2001-11-19 02:04): > written. I don't work this way. you're missing something ... but you don't know it yet :-) > > If I had to name my modus operandi, it would probably be called "sculpting" > (as in wax or clay, NOT rock). I start first with a really sloppy script, > written as fast as possible; a sort of "proof of concept" to myself that what > I want to do is even possible. ok, so now you have done a "spike" > Classes seem to split, spawn, morph, disappear > and reappear with great rapidity. I am constantly refactoring. when you are refactoring, how do you know that your refactoring is complete and functional? manual inspection? mental single stepping? how about setting up a test for this? so capture the desired behaviour in a test refactor check that the test is still running repeat > Only > gradually does the design begin to settle down and firm up to the point that > unit testing would be feasible. unit tests grow with your program. they are valuable, especially when you tend to forget nitty-gritty details. they provide for examples of how to use your code, when you come back to it in a year. > > I am curious about how others work; And how unit testing is really used: you are about writing a method providing a specific behaviour. you capture the behaviour in a unit test. you run the tests. the test will fail, because nothing is implemented. you fix the broken test. you run the tests. all tests succeed. repeat now you have a complete set of unit tests for the functionality of your application. after a while you will notice opportunities for refactoring. you run the tests. all tests succeed as this is way you left them last time. you refactor your code. you run the tests. maybe some tests break because you changed the external interface of a class. you fix the tests to adhere to the new interfaces. you run the tests. all tests succeed. you know that everything still works, because all of your unit tests succeed. you cannot forget to change some part distantly related and twice removed. you can check the validity of your code with a few keystrokes. that's great. > as a predefinition of specs or tacked on after-the-fact to convince others > that you are PC (Politically Correct). forget PCness, do what works. there are small "throw-away" projects, where unit-testing is overkill. but remember, ruby code tends to be maintainable and reusable, so you might end up building a larger program out of your little script and when this happens, you want to have your trusted set of unit tests at your side. have fun, s. -- Stefan Schmiedl EDV-Beratung, Programmierung, Schulung Loreleystr. 5, 94315 Straubing, Germany Tel. (0 94 21) 74 01 06 Public Key: http://xss.de/stefan.public shhhh ... I can't hear my code!