Sorry for posting about my own article, but I'm interested in feedback,
recommendations for future topics, etc. IBM has just published an
article I wrote about doing test first development with Ruby:
(sorry, you need to sign in (free account) to read it).
I've got an opportunity to do some more writing for them (how much
more depends on how well received/popular the articles are), and I'd
love to get some feedback from the community about what kinds of
Ruby things I should be sending their way.
···
--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)
Sorry for posting about my own article, but I'm interested in feedback,
recommendations for future topics, etc. IBM has just published an
article I wrote about doing test first development with Ruby:
(sorry, you need to sign in (free account) to read it).
I generally am opposed to registering for free content (paid stuff
is obviously different). One may visit http://www.bugmenot.com to
bypass registration.
Good article.
I've got an opportunity to do some more writing for them (how much
more depends on how well received/popular the articles are), and I'd
love to get some feedback from the community about what kinds of
Ruby things I should be sending their way.
--
thanks,
-pate
E
···
Le 24/5/2005, "pat eyler" <pat.eyler@gmail.com> a écrit:
Sorry for posting about my own article, but I'm interested in feedback, recommendations for future topics, etc. IBM has just published an
article I wrote about doing test first development with Ruby:
(sorry, you need to sign in (free account) to read it).
I've got an opportunity to do some more writing for them (how much
more depends on how well received/popular the articles are), and I'd
love to get some feedback from the community about what kinds of
Ruby things I should be sending their way.
I think it is a nice article.
OTOH I'd have loved to see some information on how to test this for network problems, since a friend of mine just had this kind of problems: how to be sure that my code won't bomb down if the dns goes mad or the network interface breaks or whatever? But probably this is out of the scope of the article.
Also, why are you putting the mock data in the DATA pseudofile instead of a real external file ?
Sorry for posting about my own article, but I'm interested in feedback, recommendations for future topics, etc. IBM has just published an
article I wrote about doing test first development with Ruby:
(sorry, you need to sign in (free account) to read it).
I've got an opportunity to do some more writing for them (how much
more depends on how well received/popular the articles are), and I'd
love to get some feedback from the community about what kinds of
Ruby things I should be sending their way.
I just started going through the article, but (as is my inclination) I took a peek at the Resources page, and I'm curious why ruby-doc.org wasn't listed.
On 24/05/05, pat eyler <pat.eyler@gmail.com> wrote:
Sorry for posting about my own article, but I'm interested in feedback,
recommendations for future topics, etc. IBM has just published an
article I wrote about doing test first development with Ruby:
(sorry, you need to sign in (free account) to read it).
I've got an opportunity to do some more writing for them (how much
more depends on how well received/popular the articles are), and I'd
love to get some feedback from the community about what kinds of
Ruby things I should be sending their way.
--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)
Sorry for posting about my own article, but I'm interested in feedback, recommendations for future topics, etc. IBM has just published an
article I wrote about doing test first development with Ruby:
(sorry, you need to sign in (free account) to read it).
I've got an opportunity to do some more writing for them (how much
more depends on how well received/popular the articles are), and I'd
love to get some feedback from the community about what kinds of
Ruby things I should be sending their way.
Sorry for the late reply but I didn't have the time to read this article before today.
First, I'd like to say that I found this article very interesting and well written (easily understable by a newbie I think).
But I have a question. The article is entitled 'Test-first programming with Ruby' but when talking about ZenTest you tell that it "can also work in reverse, loading a test suite and writing code stubs for every test" which corresponds to what this is all about. However the examples you are showing after that are examples to go from code to tests. Why didn't you show how to go from tests to code using ZenTest?
Le 24/5/2005, "pat eyler" <pat.eyler@gmail.com> a écrit:
Sorry for posting about my own article, but I'm interested in feedback,
recommendations for future topics, etc. IBM has just published an
article I wrote about doing test first development with Ruby:
(sorry, you need to sign in (free account) to read it).
I generally am opposed to registering for free content (paid stuff
is obviously different). One may visit http://www.bugmenot.com to
bypass registration.
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso
I think it is a nice article.
OTOH I'd have loved to see some information on how to test this for
network problems, since a friend of mine just had this kind of problems:
how to be sure that my code won't bomb down if the dns goes mad or the
network interface breaks or whatever? But probably this is out of the
scope of the article.
Yeah, out of scope for this one, but it sounds like an interesting problem
to write about. I think mock objects are the right answer.
Also, why are you putting the mock data in the DATA pseudofile instead
of a real external file ?
For a small amount of data, using the DATA pseudofile was easier
(keeping everything together), but as r43 has grown, I'm getting ready to
split it out into a separate file.
···
On 5/24/05, gabriele renzi <surrender_it@remove-yahoo.it> wrote:
--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)
I just started going through the article, but (as is my inclination) I
took a peek at the Resources page, and I'm curious why ruby-doc.org
wasn't listed.
Braino on my part. I think that I make less use of ruby-doc.org
than I should. I'll try to change my personal usage habit, and will
make sure it shows up in future articles.
···
On 5/24/05, James Britt <james_b@neurogami.com> wrote:
--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)
Just started with your article, and I wonder why you build a
constructor that tests for object classes, why not simply call .to_s
on the argument?
I wrote it that way to create some (artificial, but easy to see)
boundary conditions for the article, this test doesn't actually
show up in the released versions of r43. It would have been
better to be able to verify the format of the id strings, but I
wasn't able to find that kind of information about them.
Actually testing it the way I did was a bit of a stretch. In the case
of the test key '1234' you could have a Numeric, but the real keys
all seem to be alphanumeric. It's certainly possible to create an
Array that would be stringified into a valid key as well, e.g.
["1", "2", "3", "4"].
···
On 5/24/05, Brian Schröder <ruby.brian@gmail.com> wrote:
--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)
Sorry for the late reply but I didn't have the time to read this article
before today.
No problems, feedback is always good.
First, I'd like to say that I found this article very interesting and
well written (easily understable by a newbie I think).
Good, that's my target.
But I have a question. The article is entitled 'Test-first programming
with Ruby' but when talking about ZenTest you tell that it "can also
work in reverse, loading a test suite and writing code stubs for every
test" which corresponds to what this is all about. However the examples
you are showing after that are examples to go from code to tests. Why
didn't you show how to go from tests to code using ZenTest?
I did, perhaps it didn't show up very well:
Letting ZenTest write code stubs for you works the same way. If you
were to run the tool against your existing ts_r43.rb like
'ZenTest.rb ts_r43.rb', it would generate the output shown here:
1 class R43
2 def key
3 raise NotImplementedError, 'Need to write key'
4 end
5 def echo
6 raise NotImplementedError, 'Need to write echo'
7 end
8 end
Since all that ZenTest is writing for you are code stubs (which look
a *lot* like test stubs) I probably need to be more explicit about what's
going on.
···
On 6/7/05, Ghislain Mary <nospam@lunacymaze.org> wrote:
Ghislain
--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)
Disclaimer: I've never actually used ZenTest, so I may be wrong, but
having read a little about it this is my understanding...
But I have a question. The article is entitled 'Test-first programming
with Ruby' but when talking about ZenTest you tell that it "can also
work in reverse, loading a test suite and writing code stubs for every
test" which corresponds to what this is all about. However the examples
you are showing after that are examples to go from code to tests. Why
didn't you show how to go from tests to code using ZenTest?
I believe that you are misinterpreting the (admittedly ambiguous)
statement "loading a test suite and writing code stubs for every
test". From my understanding of ZenTest, the noun "test suite" would
refer to the code base to be tested plus any existing tests, and the
"code stubs" are stubs for new tests, not stubs for the code being
tested. E.g. my code has a method 'eatTaquitos' which isn't yet tested
in my existing test suite. ZenTest will detect that and create a stub
'test_eatTaquitos' (or some other, probably better, name) method. It's
a stub because ZenTest isn't smart enought to know *how* to test
'eatTaquitos', just that it still *needs* to be tested.
Does that clear up the confusion? (Or, if I'm totally off base, will
someone familiar with ZenTest clean up the mess I just made?)
>> (sorry, you need to sign in (free account) to read it).
>
> I generally am opposed to registering for free content (paid stuff
> is obviously different). One may visit http://www.bugmenot.com to
> bypass registration.
bless you.
seconded.
···
On 5/24/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
On Wed, 25 May 2005, ES wrote:
> Le 24/5/2005, "pat eyler" <pat.eyler@gmail.com> a écrit:
-a
--
> email :: ara [dot] t [dot] howard [at] noaa [dot] gov
> phone :: 303.497.6469
> My religion is very simple. My religion is kindness.
> --Tenzin Gyatso
--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)
I think it is a nice article.
OTOH I'd have loved to see some information on how to test this for
network problems, since a friend of mine just had this kind of problems:
how to be sure that my code won't bomb down if the dns goes mad or the
network interface breaks or whatever? But probably this is out of the
scope of the article.
Yeah, out of scope for this one, but it sounds like an interesting problem to write about. I think mock objects are the right answer.
I'm waiting for it
Also, why are you putting the mock data in the DATA pseudofile instead
of a real external file ?
For a small amount of data, using the DATA pseudofile was easier (keeping everything together), but as r43 has grown, I'm getting ready to split it out into a separate file.
I see, thanks for the answer
···
On 5/24/05, gabriele renzi <surrender_it@remove-yahoo.it> wrote:
I understand your motivation, but I think it is showing something that
I would rate as ugly ruby code to the world. If you really want a
string, you could have used to_str.
Please don't feel offended. I'm not even maintaining a library and
have until now never managed to really develop something test first,
let alone write an article and get it published. I feel that ugly
maybe is a bit too strong a word, but I can't find anything more
subtle.
I think it is important to show good ruby style in articles, and
ducktyping is one part of good style.
best regards,
Brian Schröder
···
On 24/05/05, pat eyler <pat.eyler@gmail.com> wrote:
On 5/24/05, Brian Schröder <ruby.brian@gmail.com> wrote:
> Just started with your article, and I wonder why you build a
> constructor that tests for object classes, why not simply call .to_s
> on the argument?
I wrote it that way to create some (artificial, but easy to see)
boundary conditions for the article, this test doesn't actually
show up in the released versions of r43. It would have been
better to be able to verify the format of the id strings, but I
wasn't able to find that kind of information about them.
Actually testing it the way I did was a bit of a stretch. In the case
of the test key '1234' you could have a Numeric, but the real keys
all seem to be alphanumeric. It's certainly possible to create an
Array that would be stringified into a valid key as well, e.g.
["1", "2", "3", "4"].
Just started with your article, and I wonder why you build a
constructor that tests for object classes, why not simply call .to_s
on the argument?
I wrote it that way to create some (artificial, but easy to see) boundary conditions for the article, this test doesn't actually show up in the released versions of r43. It would have been
better to be able to verify the format of the id strings, but I
wasn't able to find that kind of information about them.
My own experience in writing abut Ruby, especially in the common case where the audience is largely unfamiliar with Ruby, is that practices and procedures tend to get a bit skewed for reason of discourse.
Code is often not as compact is a it might otherwise be because that tends to require more background explanation. It's also hard to create good demo cases, to find the balance between a compelling problem and a 7-page discussion limit.
Has anybody collected tips and guidelines for writing about Ruby? It would be good to see more Ruby articles in high profile places (i.e. sites outside the Ruby community circle, or in widely-circulated magazines such as Linux Journal), but I wonder if people with good ideas and useful knowledge hold off because they don't know where to start or how to construct a well-organized, (reasonably) self-contained article.
James Britt
···
On 5/24/05, Brian Schröder <ruby.brian@gmail.com> wrote:
Letting ZenTest write code stubs for you works the same way. If you were to run the tool against your existing ts_r43.rb like 'ZenTest.rb ts_r43.rb', it would generate the output shown here:
1 class R43
2 def key
3 raise NotImplementedError, 'Need to write key'
4 end
5 def echo
6 raise NotImplementedError, 'Need to write echo'
7 end
8 end
Since all that ZenTest is writing for you are code stubs (which look
a *lot* like test stubs) I probably need to be more explicit about what's
going on.
Oh... sorry. That's my mistake. It is indeed very clear.
Disclaimer: I've never actually used ZenTest, so I may be wrong, but
having read a little about it this is my understanding...
Anti-disclaimer: the description below is pretty accurate for Ruby
code -> tests via ZenTest
> But I have a question. The article is entitled 'Test-first programming
> with Ruby' but when talking about ZenTest you tell that it "can also
> work in reverse, loading a test suite and writing code stubs for every
> test" which corresponds to what this is all about. However the examples
> you are showing after that are examples to go from code to tests. Why
> didn't you show how to go from tests to code using ZenTest?
I believe that you are misinterpreting the (admittedly ambiguous)
statement "loading a test suite and writing code stubs for every
test". From my understanding of ZenTest, the noun "test suite" would
refer to the code base to be tested plus any existing tests, and the
"code stubs" are stubs for new tests, not stubs for the code being
tested. E.g. my code has a method 'eatTaquitos' which isn't yet tested
in my existing test suite. ZenTest will detect that and create a stub
'test_eatTaquitos' (or some other, probably better, name) method. It's
a stub because ZenTest isn't smart enought to know *how* to test
'eatTaquitos', just that it still *needs* to be tested.
Does that clear up the confusion? (Or, if I'm totally off base, will
someone familiar with ZenTest clean up the mess I just made?)
ZenTest is capable of 'working in reverse' too though. If you've written a
nice test suite but haven't gotten around to writing code yet, ZenTest will
gleefully write stubs for the code. In fact, you could hand ZenTest a file
full of tests and a file full of code, and it will pump out test method stubs
for any untested methods and methods stubs to match any tests for which
no methods currently exist. (Have I successfully undisambiguated things?)
···
On 6/7/05, Jacob Fugal <lukfugl@gmail.com> wrote:
Jacob Fugal
--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)
