Caveats of a single developer

I first started learning ruby on rails a couple of years ago and did a small project first then started a huge project which is just now in beta. I’m the only developer for my company so the big project kept getting
put on the back burner to do smaller projects that pay the bills now. I have actually worked on the large project off and on for about a year. Since then I’ve learned a lot of better ways to do things and I’ve also upgraded rails a couple of times (I’m currently running 1.2.5 on this app).

One of the things I’ve started doing since beginning this project is behavior driven development. Here is my confession. This app is close to production and I have no test suite, I have fat controllers, skinny models, the development.log reaks of depreciation notices, and don’t even ask me if its restful. I maintain a bug tracker for the app and I am currently fixing minor bugs and still implementing new features. I can break down the refactoring process into small pieces and still do bug fixes and feature implementations, it will just take me a while to clean up the code (one guy remember). My question is this, does anyone have experience or know of a good read about writing tests for an existing app?

Here are the stats for the app so you can get an idea of the size of it.

here are some blogs i found helpful (actually, I can't read Dutch, the
2nd was, um, challenging)

http://blog.kineticweb.com/articles/2007/05/18/adding-tests-to-legacy-rails-apps
http://blog.rubyenrails.nl/articles/2007/04/26/het-testen-van-een-testloze-rails-applicatie
http://jerryr.com/2007/5/23/railsconf-2007-sessions-testing-legacy-rails-applications

Chris,

I could have written the same post almost word for word, except I started early this year. My first app was a throwaway, and then I immediately plunged into a very large project all by myself. Like you I have no tests, and my controllers go on for days.

Please do write up your refactoring experiences so knuckleheads like me can learn from your pain :slight_smile:

Done it. I started a little under 3 years ago now. After a year of Rails, I adopted TDD practices, but it pained me that my first big app had no tests.

Following Bob Martin’s advice from RailsConf 2007:

Each time you do a checkout, check the code back in just a little better than you checked it out

Here’s my advice:

Write your tests as if you don’t have code. Don’t try to think about what your code does… instead, write each test depending on what you think the outcome SHOULD be. If it passes, great! if it doesn’t, then you wrote a bad test, or you may not have your code working the way you think it does.

Don’t add any new functionality until you add a new test first. It will be a tough road… but it’s worth it in the end. I’m about 60% done adding tests to my first app, and I’ve learned a lot over the last few years.

Good luck!

Even better, comment out all your code and write the tests that should
go there, only uncommenting the behavior you need. You might find
lots of unneeded code!

http://onestepback.org/index.cgi/Tech/Ruby/FlexMockAndFluidDynamics.red

Pat

@Pat:

That’s an interesting approach :slight_smile: Pretty disruptive… I like that.

Hey,

I was a single developer as well.
My subjective and maybe false impression is that you are a bit anxious and nervous being in the vacuum all alone. Don’t panic! ©

Also, the world does not end if you don’t have the test suite (can you imagine how many projects do not have them?) and if I were you I wouldn’t spend all my efforts on creating it. Tests are most usable when you write them along with writing code. So now you could write tests for those cases where you feel it’s needed, and don’t spend your time on writing tests for everything just for the sake of tests.

Just spend your time on polishing and refactoring, once no more functionality is added, freeze it and stop it unless to fix a bug.

Cheers,
Yuri

Me too heh!

I started writing tests when I was changing some code that handled csv
data. I couldn't risk messing up the daily data import, but I had to
substantially change the way it worked. Aha I thought - better have
some good tests for this!

Amazingly, once I started looking at how to do the testing, the code
started to re-form itself into more discrete methods, and several of
them moved into the model (where unit testing is much easier). In my
case I had to spend a fair while developing the csv data for testing
import of data, but it was worth it. Now if I get any discrepancies,
I can start by running the tests and that helps me back into the
code. (My tests are still a bit tacky, but I am learning). One of
the things that kept putting me off was the seeming enormity of the
task of testing every possible condition for a particular method(s).
Others may have different views, but my guess is that it is best to
just get on and test the ones that immediately come to mind. Then the
others start to either gel or fall away as unnecessary.

I did find though, that as I tried to continue to work in tdd mode, my
end product delivery was seriously reduced. So at the moment, I am
not always building tests for everything. It would be nice if I
could, but the learning curve on writing tests is still holding me
back (and anyway, my experience is that rails is pretty rock solid -
and I tend to be a bit of a defensive programmer anyway). However, I
have changed one approach. Where in the past if I had a tricky bit of
code to write, I would bash away driving manual input and using
breakpoints, now I write a test for it and debug from there. Much
better because you get then get the test for free and repeatability of
edge cases is much more consistent.

I know I have to go back and redevelop a couple of areas of my app and
it is certainly my intention to build tests for these before I write
the code. I think the key is to just get the test framework up and
running and at least a few minimal tests working. It gives you a warm
feeling, and makes the step of adding more tests less daunting.

Much of what I have learned about Rails, and there is always something
new to pick up, has come from scanning the posts and particularly code
snippets on this group. Sadly though, there isn't a lot being posted
on tests and very little by way of examples. Maybe we could share
more on our test specifics - I suspect like us here, many rails
programmers need to get their foot on the first rung of the ladder.

I think what deters me, is that I am always pushing forward in my
understanding of how to do stuff, eg multiple models on a screen, auto
complete searching, redBox popups, factoring out views etc, etc. And
trying to write tests at the same time as figuring out how to do new
stuff is just too much for my brain. (I really like the railsCasts
perhaps there is scope for something similar for testing).

just my thoughts
Tonypm

When you start writing tests, your productivity will drop. However, the more you do it, the more productive you will be… it’s a hill-and-valley curve. The reason you’re so productive without tests is that you’re writing less code. But once you have a test, you spend less time writing functionality because you know when you’re done coding – your test passes.

Imagine a multi-table, multifield, multikeyword search. Write 10-15 test cases covering the various ways it could be used.

Then write the search. No need to keep testing the search in the browser once your tests pass.

That’s a huge gain in productivity. Thinking that tests slow you down is the wrong attitude. It’s like saying that learning a new programming language will slow you down. As said in Agile Web Development with Rails, “professional programmers write tests.”

On a closely related topic, what kind of resources are out there for
lone developers? Especially life cycle methodologies applied to teams
of Me, Myself, and I.

I'm reading _The Art of Agile Development_ (and loving it), but I'm
trying to figure out how to effectively scale these principles down.

Working on one project at a time is a luxury that doesn't come to solo
developers, and figuring out how to juggle things is ever a challenge.
Anyone recommend articles, blogs, books?

+ Beth +

@Beth:

Schedule the projects. From x to y, work on project a. From y to z, work on project b.

You can use the Scrum methodology very effectively with a team of one. Use the backlog, use sprints, and have a short meeting with yourself every day to check your progress. The most important thing is to keep yourself motivated and honest. Without anyone else looking over your code, or asking you questions, or even saying “did you do anything productive on that today?”, it’s harder to stay focused.

I recommend finding another developer that you trust, and offer to review their projects in exchange for them reviewing yours. That’s worked for me in the past. It helps to have someone ask those questions. I do code audits for other developers all the time, and I know some of the other established development firms do as well.

Good question.

Chris,

I don’t know how what you have is any different than anyone else dealing with legacy code. A lot of us were the creators of the legacy code we have to maintain.

Whatever the source, dealing with legacy code is always the same for me. Unless you’ve got gobs of free time and nothing else to do… Write tests for everything you change and all bugs (which is code that should change). It won’t happen overnight but you’ll slowly bump up your test coverage.

Thanks for all the great responses.

I'm actually not nervious about working alone, I've been a developer
for about 11 years and I've always worked alone. Not because I prefer
it or anything, I've worked for several companies but I have always
been the only programmer/IT guy at the company. Whats more odd than
that is that I just noticed. :slight_smile: Working alone has given me a lot of
experience though. I have had to build infrastructure from the ground
up as well as plan, code, and deploy all of my projects myself. I do
think there is is a benefit to people who do have a team to work
with. Chad Fowler said something about always being the worst member
in the band, so if any of you rails geniuses wants to come work with
me on something, bring it.

I do appreciate the view that I don't need to work around the clock to
get 100% test coverage. I think I'm going to write test for any new
functionality and bugs and possibly for refactoring cases as I go. If
it turns out to be a big hit, I will start vamping up test coverage
with each new release. I will try to write up anything enlightening I
stumble upon during the refactoring process, my blog is at
http://randomutterings.com.