2009-10-12 4 views
12

La sortie suivante apparaît après l'exécution de certaines tâches de rake:résultats de message de chargement et de test apparaît après l'exécution de la tâche de râteau dans l'application Rails

Loaded suite /usr/bin/rake 
Started 

Finished in 0.00042 seconds. 

0 tests, 0 assertions, 0 failures, 0 errors 

Cette sortie n'est pas utile ou nécessaire pour des tâches non liées à des tests. Je voudrais l'empêcher d'apparaître. Je suppose qu'il provient d'exiger un certain fichier ou d'inclure un certain module.

Mise à jour: Il semble que je me suis trompé et cela se produit au cours de certaines des tâches intégrées dans Rails. Voici la sortie des appareils en cours de chargement avec --trace.

$ rake db:fixtures:load --trace 

** Invoke db:fixtures:load (first_time) 
** Invoke environment (first_time) 
** Execute environment 
** Execute db:fixtures:load 
Loaded suite /usr/bin/rake 
Started 

Finished in 0.000255 seconds. 

0 tests, 0 assertions, 0 failures, 0 errors 

Répondre

11

solution peut être trouvée ici:

http://github.com/thoughtbot/shoulda/issues/#issue/59

Fondamentalement ne nécessitent pas la gemme Shoulda moins que ce soit l'environnement de test (où test/unité serait déjà nécessaire).

+0

Merci pour la réponse fowlduck. Tu avais raison. Nous avions placé l'appel config.gem à l'intérieur de environment.rb au lieu d'environnements/test.rb – Jared

+0

Dans un projet rails 3.2.2, j'ai vu ce comportement (l'unité de test s'exécutant après des tâches de rake sélectionnées) et le problème était que je devais le groupe: test,: bloc de développement. Le déplacer vers le: bloc de test (avec d'autres que j'avais mis paresseusement dans les deux) a supprimé l'appel à l'unité de test. –

1

Commencez par vérifier le modèle de test de votre Rake::TestTask. Devrait être quelque chose comme 'test/**/*_test.rb'. Pour une raison quelconque, Test :: Unit tente de trouver des tests dans l'exécutable /usr/bin/rake, ce qui signifie probablement que vous avez un modèle bidon quelque part.

Chaque fois que vous avez des problèmes de ce type, vous devez exécuter rake avec --trace pour voir quelles tâches et dépendances de tâches sont exécutées et dans quel ordre. Si la mise à jour du motif ne fonctionne pas, veuillez copier la sortie d'un cycle complet avec --trace activé dans votre question.

+0

l'un des autres développeurs que je travaille sur le projet récemment vendored tous de nos gemmes. C'est possible c'est la cause? Les seuls endroits qui appellent Rake :: TestTask se trouvent dans les répertoires vended gem et plugin. – Jared

+0

Difficile à dire sans la sortie de '--trace'. S'il n'y a pas de tâche de test explicite, vous voudrez probablement écrire le vôtre. La tâche de test par défaut ne fera rien d'utile, comme vérifier votre couverture de code. Quoi qu'il en soit, si une exécution de test se produit pour une tâche de rake arbitraire, vous avez gâché les dépendances de tâches, et vous devez utiliser '--trace' pour le déboguer. –

+0

Bob, j'ai essayé d'exécuter une tâche avec trace, mais ça ne m'a rien dit de plus. Tout ce que j'ai découvert, c'est que quoi que ce soit que les sorties cela fonctionne après que mon code soit terminé. – Jared

0

Je suis arrivé à ce fichier: ~/.rvm/rubis/ruby-1.9.2-tête/lib/ruby ​​/ 1.9.1/minitest/unit.rb

Et à la ligne 498 (juste après " def self.autorun ") Je mets:

return # the user of this computer put this here, because of reasons 

Je ne pense pas que cette méthode va me faire tomber comme lui manque ...

Questions connexes