Hmm. Just a few thoughts. I've been reading "How To Win Friends and Influence People" a fascinating and old (but not too dated) book. While going over how you need to find out want people want and motivate them using that it brought up an example where a little boy did not want to go to kindergarten. So the parents thought about the aspects of kindergarten that the child would like, in particular finger painting. And then finger painted and told the child about these things to make him excited about kindergarten, instead of dreading it.
Personally I'm a fairly negative person. I try to map out everything, and see the likely paths and outcomes, and identify any major roadblocks. Which seems great for software design on paper, and it is! But then it isn't. As seeing a mountain of hurdles overwhelmes me and keeps me from getting anything done.
So far my main approach to this has been one lectured into me by my mother (though never applied while living with her), which is the simple trick of writing the task done, getting it all out of your head and on paper. Then if that doesn't look simple enough break each piece into further pieces, perform each piece and cross it off! Hurray!
It feels good to cross things off.
But some things are still overwhelming, hell just making the list can be a confusing task (just what do I need to do...what are the smaller steps). However I think just as you can show someone else the pieces of something you do like. You can apply this on a personel level (with your team) and think about what will be awesome and fun about implementing this feature. And if you don't enjoy any part of a task. Think about how nice it will be when it's done. And in the past. And if you never enjoy anything, find a new job :)
Rant End.
Sunday, May 31, 2009
Monday, April 20, 2009
Rails: TDD, Code-first and My Failures at Testing Rant
Testing is by far the most exciting and WTF part of development for me. I get a little smile when I do some heavy refactoring and then am greeted with green! And I cry when I just spent an hour trying to test something that should just fucking work and it refuses. And oh it's because I wrote something in a retarded way. Ugh! It happens.
Road to Testing
My own testing road has been a long one. But I think I've almost gotten myself to where I need to be. This is just a rant on that.
I came into Rails via an internship with a local company. Despite the Lead Developer having experience using Unit Tests in previous languages the project had absolutely no testing. And continued to not until a year later after we realized our stability issues had to go.
Unfortunately the application had a lot of really dirty code. It was written by people learning Rails and then by people that were pretty novice at web development in general.
And as everything you'll read says, learning to write tests on a fat badly written application with no testing is simply a recipe for frustration.
Trying to Test...
We tried Test::Unit. Too unnatural, then went to Rspec and too confusing. None of these did we deeply dive into as we kept getting pulled away to other tasks. Looking back we should have firmly stated that we needed 2 weeks to learn a test suite and apply it. And that we shouldn't be bothered during that time except with emergices but live and learn.
Finally Selenium testing caught our eye. "Oh shit" we thought. This can do all that manual testing for us. And it did...sorta. Just the tests ran very slowly. And broke...all the freaking time. They were as unmaintainable as the main application. And I don't think this was really due to us writing them badly (though that was part of it) but a lot was simply issues with the Selenium tools for Rails at the time. (It's been 6 months since I touched them so maybe they've improved).
So now what? Well we put Selenium on our CRITICAL features. Ran that maybe a couple times a week. And then would deploy updates and it was successful in that Customers on the mornings after deploys were not calling about how they couldn't get work done but we made a dumb mistake. Sweet. Still lots of little issues.
I kept looking for a holy grail of testing. Some magical key maybe a script I could run that would make all my testing woes go away. Hell or just a book that told me what to do. Please tell me what to do! I know there's 20 options out there and a 100 ways to write it with any option. Why can't I find documentation that insists I do it this one way like all the other Rails stuff.
Don't get me wrong. I love modularity. But when you are new at something, you don't know which choice to make. There's so many options for Rails, honestly we should've stopped reading blog articles on testing. Learned Test::Unit and Fixtures and just did that. Once we understood that we could've looked at other options.
Efforts to provide that project with a proper test suite continued to fail. And then I left the company off to the wonderful world of freelance.
Now I have no one to blame for bad test suites but myself. But I still don't quite have the hang of it.
Current Set
My current set is Cucumber and Test::Unit with Shoulda and Factory Girl. But I feel like I'm wasting my time with Cucumber (am I?!) And though I intend to do TDD. I really don't.
I don't feel like I'm thinking through the application interface and work flow while writing tests. Sure I'm thinking through the technical side in a way that I don't do with code-first development. But is that what matters? Clients don't hire me to make another forum, they hire me to make an application for their needs/idea that doesn't exist. The challenge is not technical but a usability one.
Designing from the technical side and not the user side is just wrong. When you are doing Rails work....right? Now I'm not saying there's no way to do TDD and not be as user minded as when doing code-first development. But I haven't found it.
If you are developing something new....the technical side is not the issue. The designing a user interface and features that make sense are! Which in some ways is what makes Cucumber awesome. It makes me write down every step that the user takes. At the same time I can't see it while writing those steps....so maybe I should go build it and then write them.
When I do try TDD with Cucumber I go straight to the coding and skip Functional and Unit tests (I intend to come back to them later).
So am I failing at this? Is a proper workflow Cucumber then writing Unit/Functional tests that fail. Writing code to make those go green and then run the Cucumber test to get to the next step?
At this point I've done so much testing that I feel commited to my original design. And shit my original design will not work for the target userbase. Now I have to go adjust it and mess with all my tests.
WTF. That's way to much effort. There has to be a better right way. Maybe skipping the Unit and Functional testing till after interaction is for sure. But when you skip things you sometimes don't come back.
I understand the idea of mocking up experimental functionality but if it's not extremely experimental....shouldn't I just do it in my actual app? And if it's experimental there's no reason to write tests for it. (Until it graduates from experimental)
So I don't know about you TDD, we were friends but lately I feel like you are the programmer way of doing things and not for designers. Or maybe we just need to go out more? Yeah? Maybe?
Ok see you saturday.
Road to Testing
My own testing road has been a long one. But I think I've almost gotten myself to where I need to be. This is just a rant on that.
I came into Rails via an internship with a local company. Despite the Lead Developer having experience using Unit Tests in previous languages the project had absolutely no testing. And continued to not until a year later after we realized our stability issues had to go.
Unfortunately the application had a lot of really dirty code. It was written by people learning Rails and then by people that were pretty novice at web development in general.
And as everything you'll read says, learning to write tests on a fat badly written application with no testing is simply a recipe for frustration.
Trying to Test...
We tried Test::Unit. Too unnatural, then went to Rspec and too confusing. None of these did we deeply dive into as we kept getting pulled away to other tasks. Looking back we should have firmly stated that we needed 2 weeks to learn a test suite and apply it. And that we shouldn't be bothered during that time except with emergices but live and learn.
Finally Selenium testing caught our eye. "Oh shit" we thought. This can do all that manual testing for us. And it did...sorta. Just the tests ran very slowly. And broke...all the freaking time. They were as unmaintainable as the main application. And I don't think this was really due to us writing them badly (though that was part of it) but a lot was simply issues with the Selenium tools for Rails at the time. (It's been 6 months since I touched them so maybe they've improved).
So now what? Well we put Selenium on our CRITICAL features. Ran that maybe a couple times a week. And then would deploy updates and it was successful in that Customers on the mornings after deploys were not calling about how they couldn't get work done but we made a dumb mistake. Sweet. Still lots of little issues.
I kept looking for a holy grail of testing. Some magical key maybe a script I could run that would make all my testing woes go away. Hell or just a book that told me what to do. Please tell me what to do! I know there's 20 options out there and a 100 ways to write it with any option. Why can't I find documentation that insists I do it this one way like all the other Rails stuff.
Don't get me wrong. I love modularity. But when you are new at something, you don't know which choice to make. There's so many options for Rails, honestly we should've stopped reading blog articles on testing. Learned Test::Unit and Fixtures and just did that. Once we understood that we could've looked at other options.
Efforts to provide that project with a proper test suite continued to fail. And then I left the company off to the wonderful world of freelance.
Now I have no one to blame for bad test suites but myself. But I still don't quite have the hang of it.
Current Set
My current set is Cucumber and Test::Unit with Shoulda and Factory Girl. But I feel like I'm wasting my time with Cucumber (am I?!) And though I intend to do TDD. I really don't.
I don't feel like I'm thinking through the application interface and work flow while writing tests. Sure I'm thinking through the technical side in a way that I don't do with code-first development. But is that what matters? Clients don't hire me to make another forum, they hire me to make an application for their needs/idea that doesn't exist. The challenge is not technical but a usability one.
Designing from the technical side and not the user side is just wrong. When you are doing Rails work....right? Now I'm not saying there's no way to do TDD and not be as user minded as when doing code-first development. But I haven't found it.
If you are developing something new....the technical side is not the issue. The designing a user interface and features that make sense are! Which in some ways is what makes Cucumber awesome. It makes me write down every step that the user takes. At the same time I can't see it while writing those steps....so maybe I should go build it and then write them.
When I do try TDD with Cucumber I go straight to the coding and skip Functional and Unit tests (I intend to come back to them later).
So am I failing at this? Is a proper workflow Cucumber then writing Unit/Functional tests that fail. Writing code to make those go green and then run the Cucumber test to get to the next step?
At this point I've done so much testing that I feel commited to my original design. And shit my original design will not work for the target userbase. Now I have to go adjust it and mess with all my tests.
WTF. That's way to much effort. There has to be a better right way. Maybe skipping the Unit and Functional testing till after interaction is for sure. But when you skip things you sometimes don't come back.
I understand the idea of mocking up experimental functionality but if it's not extremely experimental....shouldn't I just do it in my actual app? And if it's experimental there's no reason to write tests for it. (Until it graduates from experimental)
So I don't know about you TDD, we were friends but lately I feel like you are the programmer way of doing things and not for designers. Or maybe we just need to go out more? Yeah? Maybe?
Ok see you saturday.
Subscribe to:
Posts (Atom)
