> Is it just me or does anyone else miss being able to create something
> quickly.
When I write customer paid for software I strive to apply the best
practices to ensure they have high quality, low bug software which is
well-factored with the goal that it is easier to maintain and extend
over its lifetime, assuming there will be developers added to the
project over its lifetime that were not there for its original
development efforts.
When I write software for myself I tend to flip flop. Sometimes I am
writing things to learn or play and I don't test. Sometimes I want to
work on my ability to write well designed testable software, so I do
test.
Also, don't forget that sometimes when producing software you need to
SPIKE some things out, which means you code upfront to investigate
(kind of like prototyping) and then when you figure out what you want
to do, or how-to do it you scratch the prototype and reimplement
w/tests.
> Once you start writing all the tests your time is now
> increased by a factor of 10.
Here's another perspective to look at it from. When you write testable
and tested software you spend less time coming back to it to track
down and fix erroneous bugs. There is a much higher risk you will have
to track down and fix erroneous bugs when you don't test (or don't
test well there is a difference).
There are also the things to account for like when you design for
testability and the fact that you usually end up with simpler
components which are easier to add to, extend or change. So as your
program grows and changes from your customer's perspective you are
able to maintain fluid momentum for changing the code as well. When
you don't test there is usually a lot of momentum in the first few
weeks, but then development slows down and even comes to a halt
because the codebase is not well factored, and bugs are much more
easily introduced with these changes and you spend more time tracking
down bugs, fixing bugs and trying to understand the codebase.
So I don't agree with the factor of 10 because when you don't test you
spend a lot more time over the life of the project tracking down bugs,
fixing bugs, and a much more difficult time changing the codebase to
grow with its users needs and your customers desires. All of the time
spent doing these things should be added to the time it took to
originally develop a feature upfront since it really wasn't done.
People also have different levels of software development skills
(design, testing, object decomposition, etc) and they can produce
things at different speeds so a factor of 10 for you may be a factor
or 0 for someone else.
> I agree with the logic in testing, but am
> I doing something wrong?
>
> Take the simple example of a controller test for an index action that
> shows all the forum posts for a user account.
>
> The controller code would be something like what is shown below, and on
> a bad day may take a minute to do (a really bad day)
> =========
> before_filter :login_required
> before_filter :find_account
>
> def index
> @posts = @account.posts
> end
> =========
>
> Now the controller tests are as following, and with the make it fail,
> make the update, make it pass strategy would could take about 10
> minutes.
> =========
>
> describe PostsController, "index" do
>
> before :each do
> @posts = mock("posts")
> @account.stub!(:posts).and_return(@posts)
> end
>
> it "should call the find account method" do
> controller.should_receive(:find...
> do :get
> end
>
> it "should assign the @account model" do
> do :get
> assigns[:account] ...
> end
>
> it "should call the login required" do
> controller.should_receive....
> do :get
> end
>
> it "should call on the account.posts" do
> @account.should_recei...
> get :index
> end
>
> it "should assign posts" do
> do_get
> assigns[:posts]....
> end
> end
>
> =========
>
> Now this is a simple example, but that is a lot of extra tests for three
> lines of code. I don't know if it is just me, but it takes away some of
> the fun in being able to see results right away.
First thing: do not stub or mock expect the object under test.
When you're testing a controller do not "stub!" the controller and do not
"should_receive" the controller. This removes the value you get for testing
the controller itself. There are exceptions to this rule, and this is largely
because people violate the use of mixins. That is for another
conversation though.
I know that Pat said that the "controller.should_receive(:login_required)" is
too much testing, but I'm going to be more forward. It is not too much testing,
it is testing the wrong thing.
> I understand that with more complex code it may be easy to make a change
> that could have unexpected effects elsewhere. In the above example,
> there is no logic that would ever get changed by accident on later
> updates at least not by anyone who knows what they are doing.
>
> Maybe I am way out in left field with the tests that I write, but the
> tests above are done using the fails, update, pass sequence. I just
> can't see the reasoning for writing all these tests for something so
> simple.
>
So when the application gradually becomes more complex do you think
you'll eventually
get to a point and say, "well I need to test this now?". Unfortunately
even if you do
do that when you get to point there's a really good chance you didn't
write the code
for testability, so the barrier to test is much higher, and it's
easier for people to
give in and not test at this point because it's now to difficult to
test, and they can't
spend a long time fixing bad code they've written.
> I guess my thing is that I like writing tests when they will eliminate a
> lot of manual testing ex automated scheduling class. This would require
> a lot of different tests to make sure that the scheduler works as it
> should. I also don't have a problem with model testing seeing as there
> may be some logic within the model that is unique to it. I do find view
> testing to be a very unenjoyable, and I haven't event looked at stories
> yet.
Testing is not about developer enjoyment. It's about producing high quality
low bug software in a way that allows you to sustain a consistent development
pace over the lifetime of the project.
Although I do get enjoyment knowing I'm producing high quality software.
> I am not trying to say that testing isn't good and that everyone is on
> the wrong track, but rather wondering if, as in the example, am testing
> more than I should be.
I think you're experiencing growing pains. Thank you for posting your
concerns and questions. I used to have some of the same questions
you're having. Hopefully
my response has been helpful to raise some counter arguments to your concerns,
Zach Dennis
http://www.continuousthinking.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
