Code71's RoR projects

[Sohan]

Dear group,
Its good to see a RoR group created.

Just to get started, I would like to present you a few projects that
we worked/working on using RoR.

1. http://www.ScrumPad.com - completely developed at Code71 lab.
2. http://www.Xerpi.com - developed in conjunction with the Xerpi
team.
3. http://www.MonkeySee.com - developed jointly by Code71 and
CodeSherpas (US based)

Please, let us know your project experience. We are having a lot of
fun with RoR. Said that, we are also finding some pains related to it
and it would be great to share the learning. My questions are as
follows-

1. Are you doing TDD?
2. If yes, are you writing Unit/functional/integration tests?

What I found is, the fixture driven unit tests are getting difficult
to manage as the code is growing in size. Please let us know how you
are managing this testing. I would also like to know about the % test
coverage that you have and target to achieve.

[Arif]

Hi Sohan bhai,

I think Hasan bhai can project some information on TDD.

[Arif]

Of course others can give you more info too. It's just that I know
hasan bhai here and hope to know all other brothers n sis here pretty
soon.

[ashabul yeameen]

I personally started to write full coverage of unit testing, and try to cover functional testing as much as possible. most of the business logic resides in models, so I think its worth. But we never write functional test script for checking output format (i.e. html). But I rarely write integration test. Our QA team check different scenarios against the use cases by some automated tools.

Complexity of maintaining fixture grows exponentially with size of code. We try to use mock whenever possible. Another useful method, if you can't avoid relations anyway, is to write the the data insertion at the beginning of the unit test script. At least you know you are not causing test failure to others when you modify data.

Did anyone try rspec? It isn't much different than rails build-in test functionality. But the reason I like this is its similarity with natural language expression, and it is fun to write in this way. I haven't tried their 'story runner' feature yet.

Btw, we created a yahoo group when we fast started working with rails. join and see previous postings.

http://tech.groups.yahoo.com/group/rails_artist/

thanks,
-Yeameen

[Arif]

I found several devs are using http://github.com/thoughtbot/shoulda/tree/master
now a days. But don't know if it's better than r-spec.

[S. M. Sohan]

Yeameen,
Good to know that you are covering your models and controllers. Regarding, RSpec, its cool! The idea stems from BDD, the so called Behavior Driven Development. The inventors of BDD advocates for TDD but they take TDD to be a rather misnomer.

We are using scenario to get a work around to complexities resulting from fixture. Using this method, you can actually specify the fixture in context of a particular controller, instead of a global fixture for a model. So, you may have multiple fixtures for a single model in different scenarios. Still, its not that easy to get way with the incremental complexities.

Another approach that I am yet to try is called Factory method driven approach. In this approach the fixture is removed by using a Factory method. More on this later, once I get some time to take a look at it. However, if you are already familiar with it, an introduction would be handy.

--
Best Wishes,
Sohan
http://www.smsohan.com
http://smsohan.blogspot.com
http://www.code71.com

[nhm tanveer hossain khan]

On Tue, Dec 2, 2008 at 10:28 PM, nhm tanveer hossain khan <ha...@somewherein.net> wrote:

nice conversation from all of you guys, just explaining test driven development for those who get into this term recently.
as you guys know whenever you are writing code you expect some way to get it working.

if this application is web based application you try to hit your browser until you feel your fix and verify cycle is finished.
as you know there is no way to get this browser based verify and fix cycle out of your box.

thus test first approach came out. you write whatever behavior you expect from your code and then write your code to make it working. as soon as you get your expectation fixed by the code you have written you stop running your unit test.

as you can guess this unit test process can be executed continuously to look after your source code, whether any of your team members wrote something unfinished which broke the previously written good code by other team members.

so the TDD is the cycle of -
write expectation - > write code -> verify -> again write expectation or fix code -> verify -> again .....

i try to keep coverage for all critical services. our QA team try to keep coverage on UI related functionality through selenium and we keep coverage through unit testing.

gradually we are adopting this approach for every type of projects we have, lately we even started test driven development for one of our PHP based applications.

when you start practicing TDD, you might feel, WHY should i care?
the reason is very simple, this TDD can help you to prove you had clear understanding about the function you have been coding for.

since i had pretty long practice with JUnit, i still prefer JUnit, RUnit and simpletest for php. but i tried RSpec and loved their syntax and even i have experimented RSpec story runner. i would say i loved the story runner concept.
perhaps my next project would start with story runner code.

more interesting i have got to know about easyB which is groovy based RSpect type BDD framework for java.
you will find my blog here

here is one of my open source projects which was developed based on test first approach. though lately i got most the cases are broken since i became lazy to updating the test cases.

thanks for nice initiative,
best wishes,

--
----------------------------------------------------
nhm tanveer hossain khan (hasan)
http://hasan.we4tech.com
----------------------------------------------------
mobile: +880 1713 090 511
aawaj: hasan15422
----------------------------------------------------
"work for fun"
"you think you are silly because you are not in right circle"
"all human beings are entrepreneurs" - m. yunus

--
----------------------------------------------------
nhm tanveer hossain khan (hasan)
http://hasan.we4tech.com
----------------------------------------------------
mobile: +880 1713 090 511
aawaj: hasan15422
----------------------------------------------------
"work for fun"
"you think you are silly because you are not in right circle"
"all human beings are entrepreneurs" - m. yunus

[nhm tanveer hossain khan]

Shoulda sounds good to me, they are based on RUnit  and RSpec based context functionality.
so you could maintain typical runit code with shouda specific api (which is more likely RSpec syntax).
i should give it a try as i like runit.

best wishes,

On Tue, Dec 2, 2008 at 9:47 PM, Arif <asm....@gmail.com> wrote:

I found several devs are using http://github.com/thoughtbot/shoulda/tree/master
now a days. But don't know if it's better than r-spec.

--

----------------------------------------------------
nhm tanveer hossain khan (hasan)
http://hasan.we4tech.com
----------------------------------------------------
mobile: +880 1713 090 511
aawaj: hasan15422
----------------------------------------------------
"work for fun"
"you think you are silly because you are not in right circle"
"all human beings are entrepreneurs" - m. yunus