Tom,
I appreciate the reply...
So would I be correct in saying that I should develop all of my spec
tests first, and then finish it up by running some cucumber tests?
Thanks!
Chris
On Jul 15, 11:34 pm, Tom Stuart t...@experthuman.com wrote:
Hi Chris,
On 16 Jul 2009, at 04:14, Chris Sund
Hi Chris,
On 16 Jul 2009, at 06:46, internetchris
ch...@silhouettesolutions.net wrote:
So would I be correct in saying that I should develop all of my spec
tests first, and then finish it up by running some cucumber tests?
You can do whatever you like. This is certainly a valid way of
On Thu, Jul 16, 2009 at 7:46 AM,
internetchrisch...@silhouettesolutions.net wrote:
Tom,
I appreciate the reply...
So would I be correct in saying that I should develop all of my spec
tests first, and then finish it up by running some cucumber tests?
Thanks!
Chris
Chris
If you follow
Hello,
On a recently setup machine, a freshly checked out project started to
fail in the strangest way. When executing 'rake spec', all the specs
would fail because of the same ArgumentError:
wrong number of arguments (0 for 1)
This gist contains the backtrace of a single failing test:
On Thu, Jul 16, 2009 at 1:48 AM, Marc Chungmch...@gmail.com wrote:
Hello,
On a recently setup machine, a freshly checked out project started to
fail in the strangest way. When executing 'rake spec', all the specs
would fail because of the same ArgumentError:
wrong number of arguments (0 for
On Wed, Jul 15, 2009 at 6:03 PM, Adam Andersonadamanderso...@gmail.com wrote:
Sometimes when features are asked to be removed it doesn't make sense to
specify that they shouldn't be there. It seems to me that removing something
from a tested app should not entail writing a failing spec for that
Very nice the ability to see your workflow helps me a ton. I guess
I needed to see what other developers did. I have a project that I
started, but then quit until I nailed down the testing. I will have to
catch up on the code I have already written, but I'm grasping the
cucumber and rspec
When something small is removed for a good reason (e.g. it causes a bug) I
sometimes find it necessary to test that it is not there.
This is especially important in a case where most programmers might look at
a line of code and think Hmm, I should add x to this method in order to
make it work but
David,
Thank you, that did it.
I vendored rails-2.3.2 and all the specs started working again. I
tried it out with 2.3.3, but I ran into a single failing spec
(SystemStackError: stack level too deep).
I'm good with 2.3.2.
-Marc
On Jul 16, 5:54 am, David Chelimsky dchelim...@gmail.com wrote:
$ gem q -rn rails | grep ^rails*
rails (2.3.2)
What's 2.3.3?
On Thu, Jul 16, 2009 at 3:34 PM, Marc Chungmch...@gmail.com wrote:
David,
Thank you, that did it.
I vendored rails-2.3.2 and all the specs started working again. I
tried it out with 2.3.3, but I ran into a single failing spec
On 15 Jul 2009, at 23:03, Adam Anderson wrote:
Sometimes when features are asked to be removed it doesn't make
sense to specify that they shouldn't be there. It seems to me that
removing something from a tested app should not entail writing a
failing spec for that change. I'm curious if
On 16 Jul 2009, at 17:28, internetchris wrote:
Very nice the ability to see your workflow helps me a ton. I guess
I needed to see what other developers did. I have a project that I
started, but then quit until I nailed down the testing. I will have to
catch up on the code I have already
rspec version 1.2.8 has been released!
* http://rspec.info
* http://rubyforge.org/projects/rspec
* http://github.com/dchelimsky/rspec/wikis
* rspec-users@rubyforge.org
* rspec-de...@rubyforge.org
Behaviour Driven Development for Ruby.
Changes:
### Version 1.2.8 / 2008-07-16
* enhancements
*
David Chelimsky wrote:
rspec version 1.2.8 has been released!
* http://rspec.info
* http://rubyforge.org/projects/rspec
* http://github.com/dchelimsky/rspec/wikis
* rspec-users@rubyforge.org
* rspec-de...@rubyforge.org
Behaviour Driven Development for Ruby.
Changes:
### Version 1.2.8 /
14 matches
Mail list logo
