Redmine

I disagree. Redmine uses standard Rails test classes (ActiveSupport::TestCase and its subclasses) that inherits from Test::Unit::TestCase. Why the Redmine Gemfile should be aware that these classes are on top of MiniTest in ruby1.9?

Here are few reasons:
- My main reason is that when the minitest gem is unbundled from Ruby, the failure occurs. I agree that this is a distro specific issue, so here are few more general:
- By not having minitest in Gemfile, you don't know which version of minitest will get into play - different versions/patchlevels of ruby 1.9.x contain different versions of minitest. Isn't this the reason of having Gemfile - to lock your dependencies? How can you be sure that newer version with some backward incompatibilities of isn't in any of the mentioned Rubies?
- AFAIK, when using Gemfile, it is customary to include all the dependencies that the app needs (and that aren't drawn in automatically by other dependencies). What is the reason of specialcasing minitest?
- Another thing is, that when doing "RAILS_ENV=production rake db:migrate", minitest shouldn't be needed at all, I don't really see the purpose of requiring it during db migration.

Bohuslav Kabrda wrote:

Here are few reasons:
- My main reason is that when the minitest gem is unbundled from Ruby, the failure occurs. I agree that this is a distro specific issue

Very true, it's a distro specific issue and I don't want to include distro specific stuff in Redmine.

- By not having minitest in Gemfile, you don't know which version of minitest will get into play - different versions/patchlevels of ruby 1.9.x contain different versions of minitest. Isn't this the reason of having Gemfile - to lock your dependencies? How can you be sure that newer version with some backward incompatibilities of isn't in any of the mentioned Rubies?

Minitest is not a direct Redmine dependency, Redmine depends on Rails for testing and uses its API. The rails version that I'm using is locked in the Gemfile (eg. 3.2.5 today) but I don't care about the version of MiniTest. I just care about the Rails API.

- AFAIK, when using Gemfile, it is customary to include all the dependencies that the app needs (and that aren't drawn in automatically by other dependencies). What is the reason of specialcasing minitest?

Do you really think that I've added all the Rails dependencies in the Redmine Gemfile? Please have a look at Gemfile.lock.

- Another thing is, that when doing "RAILS_ENV=production rake db:migrate", minitest shouldn't be needed at all, I don't really see the purpose of requiring it during db migration.

Again, I don't require 'minitest' anywhere. So I think you're gonna have this issue with any Rails app.

Jean-Philippe Lang wrote:

Bohuslav Kabrda wrote:

Here are few reasons:
- My main reason is that when the minitest gem is unbundled from Ruby, the failure occurs. I agree that this is a distro specific issue

Very true, it's a distro specific issue and I don't want to include distro specific stuff in Redmine.

- By not having minitest in Gemfile, you don't know which version of minitest will get into play - different versions/patchlevels of ruby 1.9.x contain different versions of minitest. Isn't this the reason of having Gemfile - to lock your dependencies? How can you be sure that newer version with some backward incompatibilities of isn't in any of the mentioned Rubies?

Minitest is not a direct Redmine dependency, Redmine depends on Rails for testing and uses its API. The rails version that I'm using is locked in the Gemfile (eg. 3.2.5 today) but I don't care about the version of MiniTest. I just care about the Rails API.

Yes, but still Redmine can't run without being able to require 'test/unit' (be it in whatever testing library).

- AFAIK, when using Gemfile, it is customary to include all the dependencies that the app needs (and that aren't drawn in automatically by other dependencies). What is the reason of specialcasing minitest?

Do you really think that I've added all the Rails dependencies in the Redmine Gemfile? Please have a look at Gemfile.lock.

Have you read the part "and that aren't drawn in automatically by other dependencies"? :)

- Another thing is, that when doing "RAILS_ENV=production rake db:migrate", minitest shouldn't be needed at all, I don't really see the purpose of requiring it during db migration.

Again, I don't require 'minitest' anywhere. So I think you're gonna have this issue with any Rails app.

Ah, not actually your problem (and neither mine). The problem is in prototype-rails which deals with ActionView::TestCase.class_eval in the library itself.