I've been programming for a long time, but never really done any serious
application testing. There's a mass of information on the web about
testing: TDD vs. BDD, fixtures vs. factories/mocking etc.
to:
- What mocking frameworks are people using (are Mocha or FlexMock
production ready?)
- What is the 'test/mocks' directory for in a default Rails application
-- don't you normally define your mocks in your test case?
- Should I be unit testing models *and* controllers? Or just unit
testing models and then functional testing controllers.
- What exactly does *functional testing* mean?
- Do I need to use fixtures at all in my unit tests?
- Should I be using fixtures in my functional tests?
After reading about, and trying several testing setups I have decided to
use plain old Test::Unit with the Shoulda plugin
(Companies like yours create meaningful solutions with thoughtbot). I am having is finding a
really good example of a Rails app with this kind of testing setup. Any
recommendations?
- What mocking frameworks are people using (are Mocha or FlexMock
production ready?)
we use rspec, works fine for us
- What is the 'test/mocks' directory for in a default Rails application
-- don't you normally define your mocks in your test case?
with rspec we do, so i can't tell you
- Should I be unit testing models *and* controllers? Or just unit
testing models and then functional testing controllers.
in the rails tests unit test == model
functional test == controller
rspec simply names the thing model & controller
- What exactly does *functional testing* mean?
testing the functionality of your app, i guess
- Do I need to use fixtures at all in my unit tests?
- Should I be using fixtures in my functional tests?
hmm, could be difficult to test a db app without data in the database
we normally make extensive use of fixtures, have one record for each
table minimum and of course additional for each "special case" that
needs testing
(show all invoices, show paid invoices, show unpaid...)
if you define associations you'll want to test them and so on...
if you use pagination, you'll want at least page_size + 1 records
and while developing your app and viewing the stuff in the browser
you'll find fixture data very helpfull, having some basic setup with a
default user, admin products, payments. i can't see how you could do
without them
I've been programming for a long time, but never really done any
serious
application testing. There's a mass of information on the web about
testing: TDD vs. BDD, fixtures vs. factories/mocking etc.
From my research I have a few questions that I cannot find the answers
to:
- What mocking frameworks are people using (are Mocha or FlexMock
production ready?)
I'm very happy with mocha.
- What is the 'test/mocks' directory for in a default Rails
application
The things in there are loaded for the respective environments. So to
give a concrete example, in our app we send sms to customers via a
gateway, that functionality goes through a class (lets call it
SMSProxy). The real implementation of SMSProxy posts the data to the
relevant place, but obviously we don't want that to happen in
development or testing, so we have a mock in there that just records
the fact it was called with whatever parameters.
-- don't you normally define your mocks in your test case?
- Should I be unit testing models *and* controllers? Or just unit
testing models and then functional testing controllers.
- What exactly does *functional testing* mean?
- Do I need to use fixtures at all in my unit tests?
- Should I be using fixtures in my functional tests?
There's a school of thought that in functional testing you should just
be mocking out all the model stuff and just check that the right
things are being called with the right parameters and so on. This does
avoid some duplication in your tests and will make them run faster and
so on. On the other hand, if your test asserts the Foo.do_bar is
called with arguments x,y,z but the implementation of Foo.do_bar
changes so that it now requires different parameters you'd have to
remember to change the expectation that you set.
