I'm not a paid developer, but I still feel guilty. I thought it might be entertaining to have a little "programmer confession." So let's hear an answer to this simple question: What makes you guilty about your Rails development? Mine is a bad one: I don't write tests. I understand that TDD makes sense, but I just don't do it. I've always rationalized "oh I'll figure out the whole testing thing on the next app" but 5 or 6 apps deep I've never done it. Hell, I've never even run tests for plugins, Typo, or anything. I skipped the Testing chapter in the Rails book. I know this clearly makes me a bad person. Dave T., if you're reading this, please don't repossess my copy of The Pragmatic Programmer! -Jeff
on 2006-01-12 22:39
on 2006-01-12 22:48
on 2006-01-12 23:49
On 1/12/06, Warren S. <firstname.lastname@example.org> wrote: > Have sex with baby goats or start wars. As long as you know you're guilty! This is not the place to bashing our dear President!
on 2006-01-13 00:04
--- Jeff C. <email@example.com> wrote: > anything. I skipped the Testing chapter in the > Rails book. I know this > clearly makes me a bad person. I'm guilty of that. I'm currently reading the testing chapter in the Agile book, attended a Java testing meeting last night, and can see the value of testing. But writing so many tests just to make sure retrieved data is valid seems unnecessary to me - after all, there are all sorts of validatations that can be placed in models, plus constraints, etc. in the database. It's all QA though I suppose... I don't see how TDD is faster, but if it is... csn __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
on 2006-01-13 00:53
Hey, he admitted it was only one goat... and that the goat reeeeeally liked him. Ironically enough, he passed a consensual goat sex bill under the radar a few years back. Anyhow... I'm guilty of the lack of tests too. I blame tight deadlines, and my rookie status of using Ruby and the Rails framework. That said, I would love to see a screencast of real TDD in action... maybe even vs. the non-TDD approach.
on 2006-01-13 01:11
On 1/12/06, CSN <firstname.lastname@example.org> wrote: > > or 6 apps deep I've > data is valid seems unnecessary to me - after all, > there are all sorts of validatations that can be > placed in models, plus constraints, etc. in the > database. It's all QA though I suppose... I don't see > how TDD is faster, but if it is... Is there a "Non-Testers Anonymous"? I think a 12 step program is in order here for those of us who haven't quite perfected out testing skills. ;-) Curt
on 2006-01-13 01:32
TDD is faster because you code exactly as much as you need to, and nothing more. You lay out the interface to you make it behave properly. Your're right that the tests themselves are overhead, but you end up saving enough wasted time to more than make up for it. Your code is lean, and you have confidence that it works as advertised. Then as a bonus, when you are done with a module, you have tests in place to make sure the stuff you do next, and a month from now doesn't break what you just did. No more phone calls on Friday at 4pm from screeming clients, well, less of them anyways. Pretty soon after you are in a testing mindset, you test even for small projects. Its habbit, and because they are similar tests to ones you have written a thousand times before, they take no extra time at all. Then you realize that TDD can cure world hunger, decifer who killed Kennedy, and land you an invitation to a key swapping party at Uma Thurman's house. After that you realize that TDD just makes you happy, so you start to apply it to other aspects of your life. Test Driven cooking for example - Make eggs - Fail! You don't have eggs go to the store and buy eggs. Make eggs - Pass, you have eggs to cook. Fail! You didn't turn on the stove. Turn on the stove. etc.... matt
on 2006-01-13 02:40
Jeff C. wrote: > Mine is a bad one: I don't write tests. I understand that TDD makes > sense, but I just don't do it. I've always rationalized "oh I'll figure > out the whole testing thing on the next app" but 5 or 6 apps deep I've > never done it. I too have had guilty feelings about this and I have partially resolved the problem by writing tests, but only realy really simple ones. I don't do too many unit tests, but it is possible to write a simple functional test that simply runs an action on a controller and verifies that the action worked without any unexpected exceptions being thrown. You don't *have* to write lots of assertions that all the right things have happened. The test still has some value if it runs and nothing 'blows up'. Having a simple test for each action on each controller means that you can be fairly sure that your changes have not prevented something else from working. For example, you can then remove (what you believe are) obsolete methods from your models and be pretty sure you have not broken anything. Well it works for me and seems to be a reasonable compromise between lots of work and lots of bugs.
on 2006-01-13 02:51
--- Curt H. <email@example.com> wrote: > > > sense, but I just don't do it. I've always > > > > database. It's all QA though I suppose... I don't > see > > how TDD is faster, but if it is... > > Is there a "Non-Testers Anonymous"? I think a 12 > step program is in > order here for those of us who haven't quite > perfected out testing > skills. ;-) > > Curt Hmm, is that before or after "Poor Documentors Anonymous"? ;P Oh wait, the guy from the testing session last night said that testing lends itself to good documentation. Uh oh... csn __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
on 2006-01-13 07:25
John J. wrote: > the problem by writing tests, but only realy really simple ones. > from working. For example, you can then remove (what you believe are) > obsolete methods from your models and be pretty sure you have not broken > anything. > > Well it works for me and seems to be a reasonable compromise between > lots of work and lots of bugs. These sound like "smoke tests" (as in "connect up all the boxes, turn them all on, and check that no smoke comes out") - useful to check that everything is configured properly. They also sound like tests you have written *after* coding the action. As others have pointed out, TDD is about expressing each tiny piece of requirement unambiguously (as a test) before coding the solution, and being able to focus on just what is needed to satisfy that requirement (pass the test) before moving on to the next one. Reading Kent Beck's book on Test Driven Development really impressed me with how small the steps can be, and how literally he takes "the simplest thing that could possibly work". Going to an Agile Summer School last summer confirmed this for me. I've heard for a long time, and recently been able to see for myself, that you can clearly see the difference between code developed using TDD (clean, small tightly focused methods, highly testable) and code developed "the old way". regards Justin
on 2006-01-13 07:28
>> "key swapping party at Uma Thurman's house" OMG... I'm not even going to write application code anymore... just tests...
on 2006-01-13 13:46
matthew clark wrote: > TDD is faster because you code exactly as much as you need to, and > nothing more. You lay out the interface to you make it behave > properly. Your're right that the tests themselves are overhead, but you > end up saving enough wasted time to more than make up for it. That's the first mistake I made. I only properly came to understand it recently, but tests aren't overhead at all - they're what makes it possible to change things with confidence. Without tests, if I made an internal change (maybe putting a DRB proxy in instead of a native object, for example), I had to sit back and rely on user feedback to tell me if I'd b0rked anything. Now I've got a bunch of automated users sitting in my test/ directory, actively trying to break my application, that will tell me straight away if they can't get their job done. Without screaming. Funnily enough, I came to software via ASIC design, where automated testing is so ubiquitous, you almost don't notice it. It took a few projects without it to realise how valuable a concept it was...
on 2006-01-13 20:36
Folks- What would everyone think about having a test first challenge for rails? We could run it sort of like ruby-quiz but for rails and TDD. What I envision would be something like this: * Come up with specifications for a small rails app with certain functionality. * Have someone write a full test suite and a reference version of the app that passes all the test. * Then announce the challenge and only give people the description of what the app does, a sql dump or schema.rb and a comprehensive test suite. * Give people like a week to make all the tests pass and then post everyones app somewhere so everyone else could see how others approached the problem domain. I think this would be a cool way for people to learn how to do Rails TDD in a fun competitive environment. Thoughts? Cheers- -Ezra Z. Yakima Herald-Republic WebMaster http://yakimaherald.com 509-577-7732 firstname.lastname@example.org
on 2006-01-13 21:07
Are there some good books on test-driven development I can check out? I'm quite intrigued with the concept - I'm brand new to this stuff, having picked up the pickaxe book and Agile Development with Rails two days ago. Exciting times.
on 2006-01-13 23:05
This might be fun, but it is NOT TDD, as the term is understood by those who invented it. TDD is about writing a little bit of test code, then a little bit of production code, then refactoring, and repeating over and over again. It is NOT about writing a full set of tests before you start on any code. The idea is that you'll always write just enough code to make the next test pass (and keep all older tests passing). This process is supposed to keep your code as simple as possible, while still meeting the requirements. I love and practice TDD. It is not a panacea, of course. Every way of developing software requires smart, hardworking coders and customers to be successful. (First person to find a find a method without these requirements WINS!) Jim
on 2006-01-13 23:14
I have used functional test ONE time. The time I was implementing the tests was _much_ longer than implementing controller/views. So I don't use them anymore, since controller/view code will be pretty simple anyway. Unit tests for models are great though. Implementation is fast, and they are useful. But my tests pass 80%-90% of the time at the first try if I pay close attention to the code I write. (review every character you type, and think of nicer ways) Make sure you don't hack together things, and it will be fine. But I actually do hack together tings if I want to do things as fast as possible. Most times it results in having a lot of code in your views, and that results in longer development time because it takes time to move this code to controller/helpers. It would be better if I started with helpers right away.
on 2006-01-13 23:14
On Fri, Jan 13, 2006 at 10:25:32AM -0800, Ezra Z. wrote: > suite. > * Give people like a week to make all the tests pass and then post > everyones app somewhere so everyone else could see how others > approached the problem domain. > > I think this would be a cool way for people to learn how to do Rails > TDD in a fun competitive environment. > > Thoughts? Sounds pretty cool. Definitely worth considering. I'd add the views to the provided skeleton, since the functional testing of Rails is at the controller level, and we don't want people to spend all their time dickering with prettyness instead of writing code to satisfy the test cases. To make the project a good simulation of TDD, though, you'd need to provide a series of test suites, each with a little more functionality than the last. The instructions to people would be "satisfy all the tests before starting the next lot" -- heh, we could possibly even hack "rake default" to add the next lot of test cases when it detects that the test suite passes completely. Oooh, actually, that's a really cool idea -- each time the test suite completely passes, you get a paragraph or two blurb of what the next "chunk" of development is, and more test cases get piled on. Then, when you immediately re-run rake, more tests fail, and you go around again. I'm suddenly very enthused for something like this -- but unfortunately I've already signed my weekend away to another project. Darn it. Oh well, maybe something to hack on the train (or I could perhaps use my current project as the basis for this... hmm...) - Matt
on 2006-01-13 23:27
I am not ready for the challenge but I think it is an EXCELLENT idea. I hope lots of you will take Ezra up on his idea. I'll participate in a challenge a little down the road when I am less of a threat to my own programming happiness. And if I may quote DHH (by implication) "ugliness leads to unhappiness and unhappiness leads to low productivity. Thus.... ugliness leads to low productivity. I am still suffering from coding ugliness (but it is getting more beautiful day by day). bruce
on 2006-01-14 00:25
On Jan 13, 2006, at 1:09 PM, Matthew P. wrote: >> what the app does, a sql dump or schema.rb and a comprehensive test > Sounds pretty cool. Definitely worth considering. I'd add the > last. The instructions to people would be "satisfy all the tests > of development is, and more test cases get piled on. Then, when you > - Matt Yeah the rules would have to be thought out some more. i guess what I suggested isn't really full blown TDD if you get all the tests to start with and a full schema. But something along these lines would be fun i think. And I like your idea about rake Matt, but maybe that would take too much effort in order to get started. So what about something like this instead: * A description of the functionality of the final app is posted. * It gets broken down into user stories(xp style). * The contestants get a suite of tests for one small user story at a time * Everybody gets a few days to make the tests pass and implement that story I don't know, its only an idea but I think it would be fun. And i'm open for suggestions. If enough people want to take part in this then I will try to get it organized. So if anyone is interested respond to this thread and say so. if there's enough people then we can come up with real rules and a gameplan and move forward from there. This should probably be a very small app with maybe 4 or 5 user stories needed to finish the whole thing so it doesn't take too much time for anyone to finish. Cheers- -Ezra Z. Yakima Herald-Republic WebMaster http://yakimaherald.com 509-577-7732 email@example.com
on 2006-01-14 02:13
That sounds like a really interesting idea. I would try to make time for it.
on 2006-01-14 05:05
I'll do it. I'm a long time tester, burgeoning Rubista. Sounds like fun. matt clark
on 2006-01-14 05:23
As the original guilty non-tester, I'm in! -Jeff