Forum: Ruby Best practices for library development?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2c7c807a1df0c76a8fc823c709b501a9?d=identicon&s=25 Victor Shepelev (Guest)
on 2006-05-30 14:16
(Received via mailing list)
Hi all.

I'd like somebody to share their experience in organizing library
development, including:

1. test-driven development
2. code coverage analysis (through rcov?), which would be automathically
performed after each test
3. version control (through SVN?)
4. optional code speed analysis (like benchmarking "how long it rans",
profiling "what rans so long") after each test
5. optional packaging (through rake? rant?) and uploading to (rubyforge?
sourcefoge?)

All experiences are welcome.

Big thanks!

Victor.
8d775a4f841200707929b36728efcccf?d=identicon&s=25 Suraj N. Kurapati (Guest)
on 2006-05-30 16:23
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Victor Shepelev wrote:
> 4. optional code speed analysis (like benchmarking "how long it rans",
> profiling "what rans so long") after each test

See the 'profile' library provided in Ruby core.

ruby -r profile
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEfFTnmV9O7RYnKMcRAspCAJ9jrtB3qER8px6fV7LOuB8jvlM2mACgpcVY
jeMAo7c1AuHZ63cynsPelE4=
=EPvT
-----END PGP SIGNATURE-----
2c7c807a1df0c76a8fc823c709b501a9?d=identicon&s=25 Victor Shepelev (Guest)
on 2006-05-30 16:30
(Received via mailing list)
From: Suraj N. Kurapati [mailto:skurapat@ucsc.edu]
Sent: Tuesday, May 30, 2006 5:22 PM
> Victor Shepelev wrote:
> > 4. optional code speed analysis (like benchmarking "how long it rans",
> > profiling "what rans so long") after each test
>
> See the 'profile' library provided in Ruby core.
>
> ruby -r profile

No-no :)
I know, how to do it _technically_.
What I what to know is how to _organize_ all the task.
Just for now I do only unit-tests, but _when_ to run benchmarking /
profiling / coverage analysis / dependency analysis and so on? Must
those
tasks be ran automataically? When (after any code change, like unit
tests?)
This is a question.

V.
34f159f89cbd1d9beac0276f5a7af552?d=identicon&s=25 John Gabriele (Guest)
on 2006-05-30 16:39
(Received via mailing list)
On 5/30/06, Victor Shepelev <vshepelev@imho.com.ua> wrote:
> Hi all.
>
> I'd like somebody to share their experience in organizing library
> development, including:
>
> 1. test-driven development

Yes.

Test::Unit I believe. "require 'test/unit'".

> 2. code coverage analysis (through rcov?), which would be automathically
> performed after each test

Never used rcov, but it sounds like something you'd run via a rakefile.

> 3. version control (through SVN?)

Besides CVS, that's probably the most common these days. Working
without version control is like swinging on the trapeze without a net.

> 4. optional code speed analysis (like benchmarking "how long it rans",
> profiling "what rans so long") after each test
> 5. optional packaging (through rake? rant?) and uploading to (rubyforge?
> sourcefoge?)

Dunno about the benchmarking, but as far as optional packaging, my
guess is that you should indeed be making a gem. FWIU, when you create
a RubyForge project and upload a gem, it automagically becomes
available to the world via "gem install --remote".
Fc784eadb3b54531fdc3d2053db6f83f?d=identicon&s=25 Mat Schaffer (Guest)
on 2006-05-30 18:40
(Received via mailing list)
On May 30, 2006, at 10:27 AM, Victor Shepelev wrote:
>
> No-no :)
> I know, how to do it _technically_.
> What I what to know is how to _organize_ all the task.
> Just for now I do only unit-tests, but _when_ to run benchmarking /
> profiling / coverage analysis / dependency analysis and so on? Must
> those
> tasks be ran automataically? When (after any code change, like unit
> tests?)
> This is a question.

Personally, I don't think I'd want my tests run after *every*
change.  But you might want to look into subversion's hook scripts.
(post-commit, pre-commit, etc...).  The would allow the repository to
run all the tests/profiling/coverage via rake and email the results
to interested parties upon every commit.

BUT, I wouldn't focus too much on getting a lot of testing and
profiling set up if you're just getting started.  Although ruby makes
most of this stuff really easy, you'll still burn time and energy
that might be better focused on the real task.  Don't optimize too
early.
-Mat
Dd76a12d66f843de5c5f8782668e7127?d=identicon&s=25 Mauricio Fernandez (Guest)
on 2006-05-30 18:56
(Received via mailing list)
On Tue, May 30, 2006 at 11:27:51PM +0900, Victor Shepelev wrote:
> No-no :)
> I know, how to do it _technically_.
> What I what to know is how to _organize_ all the task.
> Just for now I do only unit-tests, but _when_ to run benchmarking /
> profiling / coverage analysis / dependency analysis and so on? Must those
> tasks be ran automataically? When (after any code change, like unit tests?)
> This is a question.

As for coverage analysis: I run rcov before committing to make sure I'm
not
checking in (lots of) untested code. This is how the task can be defined
in
Rake:

require 'rcov/rcovtask'
desc "Create a cross-referenced code coverage report."
Rcov::RcovTask.new do |t|
  t.libs << "ext/rcovrt"
  t.test_files = FileList['test/test*.rb']
  t.rcov_opts << "--callsites"  # comment to disable cross-references
  t.verbose = true
end

and in Rant it'd be:

require 'rcov/rant'
desc "Create a cross-referenced code coverage report."
gen Rcov do |g|
  g.libs << "ext/rcovrt"
  g.test_files = sys['test/test*.rb']
  g.rcov_opts << "--callsites"  # comment to disable cross-references
end

This way  {rake,rant} rcov  will generate a XHTML report and show
another
on stdout.

If your commits are small enough (or should I say "atomic"?), running
the
tests just before committing (say with the pre-commit hook of your VCS)
might
suffice. Otherwise (larger commits, or tests that don't want to pass)
autotest
would be the way to go, I guess.


Regarding profiling, I don't think it makes any sense to run that
automatically in general.
2c7c807a1df0c76a8fc823c709b501a9?d=identicon&s=25 Victor Shepelev (Guest)
on 2006-05-30 19:09
(Received via mailing list)
From: Mauricio Julio Fernandez Pradier [mailto:ferferse@telefonica.net]
On
Behalf Of Mauricio Fernandez
Sent: Tuesday, May 30, 2006 7:53 PM
> > > ruby -r profile
>
>   t.test_files = FileList['test/test*.rb']
>   g.test_files = sys['test/test*.rb']
> autotest
> would be the way to go, I guess.
>
>
> Regarding profiling, I don't think it makes any sense to run that
> automatically in general.

Thanks Mauricio. It's just what I've want to hear.

> Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby

V.
This topic is locked and can not be replied to.