db:seed in rake tasks and questions

[Mathieu Allaire]

Hi!

I'm trying out the gem, moving from a custom minitest bootstrap, my goal here is to better organize my tests and try to follow some kind of convention! I have some questions though!

First question, how could I add a rake db:seed right after the db:test:prepare using your gem? What would be the best way to achieve this? Previously, i was directly creating a new task, i.e

Rake::TestTask.new('test' => ['db:test:prepare', 'db:seed']) do |t|

  t.pattern = 'spec/**/*_spec.rb'

end

Should I overwrite all your rake tasks or there's a better way to do it? 

Second question, in this article: http://alindeman.github.com/2012/11/11/rspec-rails-and-capybara-2.0-what-you-need-to-know.html -- their request test (which are supposed to be integration test?) looks much more like a single controller test to me (at least if you campire to the everydayrails article bellow)? I struggle draw the separation between controller tests request/integration tests...

If this is controller tests: http://everydayrails.com/2012/04/07/testing-series-rspec-controllers.html

and if this is now feature tests: everydayrails.com/2012/04/24/testing-series-rspec-requests.html

what should be in the requests/integration test directory?

From that article: http://blog.plataformatec.com.br/2012/06/improving-the-integration-between-capybara-and-rspec/  -- where they say "The Rails’ integration runner is built on top of rack-test, a great small gem that adds support to methods like get, post,put and delete and handle the rack request and response objects."

But ActionController::TestCase::Behavior (http://api.rubyonrails.org/classes/ActionController/TestCase/Behavior.html) have these methods as well, why not simply using controller tests?

Third question, is it just me or the minitest-spec-rails does not take advantage of extend MiniTest::Spec::DSL and still trick the ancestry?

Sorry for all these questions, I'm just trying to wrap my head with all the incoherence between the rails test guides, rspec and minitest :P

M.

[Mike Moore]

On Mon, Apr 1, 2013 at 2:07 PM, Mathieu Allaire <mathieu...@gmail.com> wrote:

Hi!

I'm trying out the gem, moving from a custom minitest bootstrap, my goal here is to better organize my tests and try to follow some kind of convention! I have some questions though!

First question, how could I add a rake db:seed right after the db:test:prepare using your gem? What would be the best way to achieve this? Previously, i was directly creating a new task, i.e

Rake::TestTask.new('test' => ['db:test:prepare', 'db:seed']) do |t|

  t.pattern = 'spec/**/*_spec.rb'

end

Should I overwrite all your rake tasks or there's a better way to do it? 

Check out Rake::Task#enhance

http://rake.rubyforge.org/classes/Rake/Task.html#M000112

Rake::Task["db:test:prepare"].enhance do

  Rake::Task["db:seed"].invoke # Run after prepare

end

Second question, in this article: http://alindeman.github.com/2012/11/11/rspec-rails-and-capybara-2.0-what-you-need-to-know.html -- their request test (which are supposed to be integration test?) looks much more like a single controller test to me (at least if you campire to the everydayrails article bellow)? I struggle draw the separation between controller tests request/integration tests...

If this is controller tests: http://everydayrails.com/2012/04/07/testing-series-rspec-controllers.html

and if this is now feature tests: everydayrails.com/2012/04/24/testing-series-rspec-requests.html

what should be in the requests/integration test directory?

Rails' integration tests differ from controller tests in that they can (should?) test more than one controller. You'd use an integration test to log in using the SessionsController and make sure that only that user's widgets are show in the WidgetsController.

I dislike the name "integration" for these tests. But I was not able to convince the core team to change it. The fact of the matter is that a controller test is an integration test (and not a unit test, which it should be) because its so difficult to isolate the logic because of how the controller was designed. So the lines can get blurry between controller and integration tests.

More thoughts on this here:

http://blowmage.com/2012/07/12/rails-tests-placement

 

From that article: http://blog.plataformatec.com.br/2012/06/improving-the-integration-between-capybara-and-rspec/  -- where they say "The Rails’ integration runner is built on top of rack-test, a great small gem that adds support to methods like get, post,put and delete and handle the rack request and response objects."

But ActionController::TestCase::Behavior (http://api.rubyonrails.org/classes/ActionController/TestCase/Behavior.html) have these methods as well, why not simply using controller tests?

Capybara has its own mechanism for invoking web requests. The API is just different. In previous releases you'd have the Rack::Test API along side the Capybara API, which was confusing and buggy. This is also why I have separated the minitest-rails-capybara tests completely from the integration tests. The implementation is separate and the Capybara feature tests only have the Capybara API.

https://github.com/blowmage/minitest-rails-capybara

 

Third question, is it just me or the minitest-spec-rails does not take advantage of extend MiniTest::Spec::DSL and still trick the ancestry?

The latest version does use MiniTest::Spec::DSL. Ken and I have traded implementation notes about implementing the DSL.

My thoughts on the MiniTest::Spec::DSL are here, in case anyone is unaware.

http://blowmage.com/2013/03/18/minitest-rails-roadmap

 

Sorry for all these questions, I'm just trying to wrap my head with all the incoherence between the rails test guides, rspec and minitest :P

Its a big subject. I appreciate the questions. Let me know if you have anymore.

[Mathieu Allaire]

On Monday, April 1, 2013 8:35:00 PM UTC-4, Mike Moore wrote:

On Mon, Apr 1, 2013 at 2:07 PM, Mathieu Allaire <mathieu...@gmail.com> wrote:

Hi!

I'm trying out the gem, moving from a custom minitest bootstrap, my goal here is to better organize my tests and try to follow some kind of convention! I have some questions though!

First question, how could I add a rake db:seed right after the db:test:prepare using your gem? What would be the best way to achieve this? Previously, i was directly creating a new task, i.e

Rake::TestTask.new('test' => ['db:test:prepare', 'db:seed']) do |t|

  t.pattern = 'spec/**/*_spec.rb'

end

Should I overwrite all your rake tasks or there's a better way to do it? 

Check out Rake::Task#enhance

http://rake.rubyforge.org/classes/Rake/Task.html#M000112

Rake::Task["db:test:prepare"].enhance do

  Rake::Task["db:seed"].invoke # Run after prepare

end

Good thanks! I guess it also correct to write our own rake tasks, since I also have libraries code to test (/test/libraries) and will need to have a custom task for that anyway...

 

Second question, in this article: http://alindeman.github.com/2012/11/11/rspec-rails-and-capybara-2.0-what-you-need-to-know.html -- their request test (which are supposed to be integration test?) looks much more like a single controller test to me (at least if you campire to the everydayrails article bellow)? I struggle draw the separation between controller tests request/integration tests...

If this is controller tests: http://everydayrails.com/2012/04/07/testing-series-rspec-controllers.html

and if this is now feature tests: everydayrails.com/2012/04/24/testing-series-rspec-requests.html

what should be in the requests/integration test directory?

Rails' integration tests differ from controller tests in that they can (should?) test more than one controller. You'd use an integration test to log in using the SessionsController and make sure that only that user's widgets are show in the WidgetsController.

I dislike the name "integration" for these tests. But I was not able to convince the core team to change it. The fact of the matter is that a controller test is an integration test (and not a unit test, which it should be) because its so difficult to isolate the logic because of how the controller was designed. So the lines can get blurry between controller and integration tests.

More thoughts on this here:

http://blowmage.com/2012/07/12/rails-tests-placement

Ok that helps. Now the way I see it, controller tests would be perfect to test response code, headers, body, etc. for let say the rails API part, since it really test each method one by one (which would kinda be unit tests for controllers). Am I correct in my assumptions?

 

From that article: http://blog.plataformatec.com.br/2012/06/improving-the-integration-between-capybara-and-rspec/  -- where they say "The Rails’ integration runner is built on top of rack-test, a great small gem that adds support to methods like get, post,put and delete and handle the rack request and response objects."

But ActionController::TestCase::Behavior (http://api.rubyonrails.org/classes/ActionController/TestCase/Behavior.html) have these methods as well, why not simply using controller tests?

Capybara has its own mechanism for invoking web requests. The API is just different. In previous releases you'd have the Rack::Test API along side the Capybara API, which was confusing and buggy. This is also why I have separated the minitest-rails-capybara tests completely from the integration tests. The implementation is separate and the Capybara feature tests only have the Capybara API.

https://github.com/blowmage/minitest-rails-capybara

 

Ok, good. So if I have feature tests with capybara (/test/features/), I won't really have any "integration" tests using Rack::Test API (/test/integration), right? Capybara takes care of both the integration and acceptance parts (in my head at least), Capybara just use a more complete/robust API compared to Rack::Test. Once again, are my assumptions correct?

 

Third question, is it just me or the minitest-spec-rails does not take advantage of extend MiniTest::Spec::DSL and still trick the ancestry?

The latest version does use MiniTest::Spec::DSL. Ken and I have traded implementation notes about implementing the DSL.

You guys should merge then if both projects converge  :) Less confusing for unfamiliar people ;)

 

My thoughts on the MiniTest::Spec::DSL are here, in case anyone is unaware.

http://blowmage.com/2013/03/18/minitest-rails-roadmap

 

Sorry for all these questions, I'm just trying to wrap my head with all the incoherence between the rails test guides, rspec and minitest :P

Its a big subject. I appreciate the questions. Let me know if you have anymore.

Thanks for your insight! 

[Mike Moore]

On Mon, Apr 1, 2013 at 8:41 PM, Mathieu Allaire <mathieu...@gmail.com> wrote:

Good thanks! I guess it also correct to write our own rake tasks, since I also have libraries code to test (/test/libraries) and will need to have a custom task for that anyway...

minitest-rails will create those tasks for you. You can run the following to run all tests under test/libraries:

rake minitest:libraries

Ok that helps. Now the way I see it, controller tests would be perfect to test response code, headers, body, etc. for let say the rails API part, since it really test each method one by one (which would kinda be unit tests for controllers). Am I correct in my assumptions?

I don't like my controller tests to test more than the response code and any affects the request may make. Creating a new record in the DB, deleting a record from the DB, etc. I try to treat controller tests like unit tests, but again by definition they are integration tests. If there is any specific logic I want to test (e.g. is a link visible in the UI) I'll extract that code to a different object and unit test it there.

Ok, good. So if I have feature tests with capybara (/test/features/), I won't really have any "integration" tests using Rack::Test API (/test/integration), right? Capybara takes care of both the integration and acceptance parts (in my head at least), Capybara just use a more complete/robust API compared to Rack::Test. Once again, are my assumptions correct?

I wouldn't say its a more complete API, just a different API. I don't think its a "better" API than Rack::Test, but it will drive a browser and that's the real benefit as I see it.

You guys should merge then if both projects converge  :) Less confusing for unfamiliar people ;)

We've discussed it, but I'm happy with both existing. minitest-rails encompasses a much larger set of changes than minitest-spec-rails. We'll see where it goes.