[RUBY] Rspec, TDD (1)

Ravi de vous rencontrer. À partir du mois d'avril, j'ai changé de travail de l'industrie médicale à un ingénieur Web. L'expérience Ruby est d'environ 2 mois.

Cela fait un mois et demi que j'ai rejoint la société, et en plus de petites corrections, j'ai progressivement développé de nouvelles fonctions, et je ressens la croissance petit à petit (je vous le dis).

Lors du développement d'une nouvelle fonction, on m'a dit "Veuillez écrire un test" et quand j'ai regardé le code du test, j'étais dans un état "Je ne sais pas comment écrire ...", donc j'ai donné la priorité à l'étude pour le test. Je suis. Je sais en quelque sorte (je sens) dans quelles conditions le test doit être fait, mais je pense qu'il est nécessaire de s'habituer à la notation propre à Rspec.

Actuellement, j'étudie en référence aux livres et articles suivants. Everyday Rails-Introduction to Rails Testing with RSpec Introduction à RSpec utilisable, Partie 1 "Comprendre la syntaxe de base et les fonctions utiles de RSpec" Développement piloté par les tests

Pour rappel, je quitterai petit à petit le processus d'étude du test sous forme d'article.

En premier lieu, si vous ne pouvez pas faire confiance au test que vous avez écrit, il ne démarrera pas ...

Quels sont les avantages de passer un test en premier lieu?

1. Réduction des coûts pour l'ensemble du test

――En écrivant régulièrement des tests automatiques, vous pouvez développer de nouvelles fonctions tout en confirmant que les fonctions existantes fonctionnent comme prévu. --Il peut être garanti que la fonction d'origine n'est pas détruite lors du refactoring.

2. Devenez résistant aux changements de l'environnement

• Vous pouvez étudier l'impact des modifications de version telles que les mises à jour ruby, rails et gem.

3. Le test lui-même devient un document d'utilisation

――Il aide les autres à comprendre les spécifications car il montre les détails du comportement attendu.

• Ce sera l'occasion de reconsidérer les spécifications et l'interface

4. Aide à maintenir la granularité du code

• Les méthodes et actions difficiles à écrire des tests ont tellement de rôles, ce qui vous donne l'occasion de repenser votre implémentation.

5. Amélioration de l'efficacité globale du développement

--C'est tout. Le développement est beaucoup plus sûr et plus sécurisé que les tests manuels et le déploiement de la prière

Configuration Rspec

• Ajouté à Gemfile car il n'est pas inclus dans Rails par défaut → installation du bundle

Gemfile

group :development, :test do
  gem 'rspec-rails', '~> 3.8.0'
end

--Création d'un DB de test

config/database.yml

test:
  <<: *default
  database: db/test.sqlite3

Exécutez bin / rails db: create: all

Paramètres Rspec

Exécutez bin / rails g rspec: install Le répertoire de stockage des spécifications, le fichier d'assistance, le fichier de configuration sont créés

.rspec

--format documentation

Si vous l'ajoutez, les informations de sortie seront plus faciles à lire.

--Installez binstub et spring pour améliorer l'efficacité du test Rspec

À propos de binstub À propos de Spring

gemfile

group :development do
  gem 'spring-commands-rspec'
end

Exécutez $ bundle exec spring binstub rspec Vous pouvez maintenant exécuter le test avec $ bin / rspec

Vérifiez d'abord la syntaxe de base

--describe: Déclaration de regroupement de tests, emboîtable --it: Regrouper les tests en unités appelées exemples

• attend (A) .to eq B: Test qui s'attend à ce que A soit B

sample_spec.rb

Rspec.describe 'Calcul' do
  it '100 +100 est 200' do
   expect(100 + 100).to eq 200
  end
  it '100 *100 est 10000' do
    expect(100 * 100).to eq 10000
  end
end

--context: Grouper par condition --before: Dans de nombreux cas, la préparation des données et les actifs avant l'exécution du test, qui sont toujours appelés avant l'exécution de l'exemple, sont effectués.

• Faites attention lorsque vous utilisez des variables car avant et elles ont des portées différentes.

--let (: A) {B}: B peut être appelé A --let est une évaluation retardée et ne sera pas utilisée tant qu'elle ne sera pas appelée --let!: La valeur définie avant d'exécuter l'exemple est créée, cela peut être mieux lorsque le test échoue en raison d'un retard d'évaluation

--subject: peut regrouper des objets sous test

• Dans ce cas, utilisez is_expected

--shared_example, it_behaves_like: peut être réutilisé lorsque l'exemple n'est pas DRY

--shared_context, include_context: le contexte peut être réutilisé

Pour le moment, c'est la fin. Je comprends les bases, donc j'écrirai de plus en plus