Caveats of a single developer

Rails
1

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.

±---------------------±------±------±--------±--------±----±------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
±---------------------±------±------±--------±--------±----±------+
| Controllers | 4786 | 4392 | 30 | 213 | 7 | 18 |
| Helpers | 198 | 151 | 0 | 11 | 0 | 11 |
| Models | 528 | 480 | 36 | 28 | 0 | 15 |
| Libraries | 164 | 92 | 3 | 7 | 2 | 11 |
| Components | 0 | 0 | 0 | 0 | 0 | 0 |
| Integration tests | 0 | 0 | 0 | 0 | 0 | 0 |
| Functional tests | 2382 | 1706 | 62 | 275 | 4 | 4 |
| Unit tests | 400 | 280 | 40 | 40 | 1 | 5 |
±---------------------±------±------±--------±--------±----±------+
| Total | 8458 | 7101 | 171 | 574 | 3 | 10 |
±---------------------±------±------±--------±--------±----±------+
Code LOC: 5115 Test LOC: 1986 Code to Test Ratio: 1:0.4

2

On Nov 8, 1:28 pm, “Chris B.” [email protected] wrote:

production and I have no test suite, I have fat controllers, skinny models,
±---------------------±------±------±--------±--------±----±------+
±---------------------±------±------±--------±--------±----±------+
| Total | 8458 | 7101 | 171 | 574 | 3 | 10 |
±---------------------±------±------±--------±--------±----±------+
Code LOC: 5115 Test LOC: 1986 Code to Test Ratio: 1:0.4

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

3

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:

4

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!

5

@Pat:

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

6

On Nov 8, 2007 6:29 PM, Brian H. [email protected] wrote:

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.

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

7

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! (c)

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

On Nov 8, 2007 10:28 PM, Chris B. [email protected] wrote:

production and I have no test suite, I have fat controllers, skinny models,
±---------------------±------±------±--------±--------±----±------+
| Integration tests | 0 | 0 | 0 | 0 | 0 | 0 |

–
Best regards,
Yuri L.

8

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

9

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 +
10

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 D. with
Rails,
“professional programmers write tests.”

11

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.

–
Jeff S.
http://thequeue.net/blog/
Microsoft MVP

12

@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.

13

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 F. 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.

On Nov 9, 12:12 pm, “Jeff S.” [email protected]

14

good luck, i learned ruby on rails in a company with experienced
developers who kicked my *** when i didn’t write tests :wink:

but for everybody who intends to start writing tests right now, rspec
may be a good starting point instead of using the test-suite

http://rspec.rubyforge.org/

it wraps the testsuite in some nice syntax and adds a few additional
functions that make live easy.