# Run code run!

**URL:** <https://www.ruby-forum.com/t/run-code-run/194718>\
**Category:** Ruby\
**Created:** [September 9, 2010, 2:42pm UTC](https://www.ruby-forum.com/t/run-code-run/194718 "2010-09-09T14:42:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![eugen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ebca7d/32.png) [@eugen](https://www.ruby-forum.com/u/eugen)\
**Post date:** [September 9, 2010, 2:42pm UTC](https://www.ruby-forum.com/t/run-code-run/194718/1 "2010-09-09T14:42:13Z")

</div>

Hi,

What is the best practice to code writing cycle for a typical ruby  
project? What are you using most often ?

Here are two possibilities that I can think of

A) Run code as frequently as you can

1. Think about design
2. Write little bit of code (code in small steps)
3. Go to check for API documentation to make sure I use API correct
4. Run code (with or without UT)
5. Fix errors
6. Start from 1)

B) Run code as late as you can

1. Think about design
2. Write down code mixed with a lot of comments and to do’s
3. Continue 1) and 2) until you think problem is solved.
4. Run Code
5. Fix Errors
6. Check API
7. Continue 4), 5),6) until problem is solved (all UT pass)

---

<div class="post-metadata">

**Author:** ![eugen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ebca7d/32.png) [@eugen](https://www.ruby-forum.com/u/eugen)\
**Post date:** [September 9, 2010, 4:02pm UTC](https://www.ruby-forum.com/t/run-code-run/194718/2 "2010-09-09T16:02:27Z")

</div>

would probably be close to A) but with automated testing injected in the  
loop.

---

<div class="post-metadata">

**Author:** ![eugen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ebca7d/32.png) [@eugen](https://www.ruby-forum.com/u/eugen)\
**Post date:** [September 9, 2010, 7:17pm UTC](https://www.ruby-forum.com/t/run-code-run/194718/3 "2010-09-09T19:17:29Z")

</div>

On Sep 9, 2010, at 08:41, Eugen C. wrote:

> A) Run code as frequently as you can
> 
> 1. Think about design

1.1) write unit tests based on that design

(Look at the API before you write code:)

> 1. Go to check for API documentation to make sure I use API correct

> 1. Write little bit of code (code in small steps)

3.1) make sure that the code you’ve written is covered by some test  
3.2) run unit tests and make sure that all the ones that used to pass  
pass, and hopefully some new ones pass as well.

> 1. Run code (with or without UT)
> 2. Fix errors
> 3. Start from 1)

The main problem with just running the code (and not unit tests) is  
that the way you test the code, you might not use all the  
functionality. Unit tests should cover it. It’s a good idea to run  
the code as a real user too, but if that’s all you’re doing, you might  
never actually test the code you’ve written that covers atypical  
operations.

The other thing you might want to throw in here at step 7 or so is  
“refactor”. Every once in a while, maybe once you’ve added a big  
functional chunk, go back over the code and say to yourself “What do I  
have here that I don’t need? Do I have any repeated code? Could I  
simplify any of this?”

Ben