रेल्स में थ्री-फेज पैटर्न के साथ टेस्ट लेखन में महारत हासिल करें

(यह प्रैक्टिसिंग रेल्स से एक छोटा अंश है। पहला अध्याय मुफ्त पाने के लिए यहां साइन अप करें!)

तो, आप एक नए ऐप पर काम कर रहे हैं, और रेल्स ने आपके लिए एक टेस्ट उत्पन्न किया:

require 'test_helper'
class BugTest < ActiveSupport::TestCase
  # test "the truth" do
  #   assert true
  # end
end

आप इसे अनकमेंट करते हैं, एक नाम लेकर आते हैं, और आप अपना टेस्ट लिखने के लिए तैयार हैं, है ना? लेकिन फिर क्या? आप पहले क्या लिखते हैं? आपके टेस्ट कोड को कैसा दिखना चाहिए?

यदि आप एक सरल पैटर्न का पालन करते हैं, तो आप उन स्टब्ड आउट कोड की लाइनों को स्पष्ट, अच्छी तरह से संरचित टेस्ट केस में बदल देंगे।

थ्री-फेज टेस्ट पैटर्न

आपके टेस्ट केस तीन चरणों में काम करने चाहिए:

1. पहले, आप कुछ सामान सेट अप करते हैं ("व्यवस्थित करें")
2. फिर, आप कुछ करते हैं ("कार्य करें")
3. फिर, आप सुनिश्चित करते हैं कि जो आप होने की उम्मीद करते थे, वह वास्तव में हुआ। ("दावा करें")

उदाहरण के लिए, कल्पना करें कि आप रूबी में एक एरे पर एक मेथड का टेस्ट कर रहे थे। इस पैटर्न का पालन करते हुए, आपका टेस्ट इस तरह दिख सकता है:

test "Array#sort will sort an array of numbers" do
  # arrange
  unsorted_array = [7, 4, 2, 3]
  # act
  sorted_array = unsorted_array.sort
  # assert
  assert_equal [2, 3, 4, 7], sorted_array
end

काफी सरल। लेकिन टेस्ट के हर हिस्से के लिए एक जगह है, और टेस्ट का लगभग हर चरण आपको बताता है कि इसे कैसे लिखना है।

कभी-कभी, आपको एक व्यवस्थित चरण की आवश्यकता नहीं होगी, या कार्य और दावा चरण संयुक्त होंगे। लेकिन जब आप अपने टेस्ट लिखते हैं तो सभी तीन चरणों के बारे में सोचना अभी भी मदद करता है।

दावा चरण की गोटचा

दावा चरण के लिए एक ट्रिक है: आपको दावा चरण में उसी तर्क का उपयोग नहीं करना चाहिए जिसका उपयोग कार्य चरण ने किया था। आपको हमेशा उसी उत्तर तक दो रास्ते लेने चाहिए। अन्यथा, आप उस कोड में बग्स को नोटिस नहीं करेंगे जिसे आप कॉल कर रहे हैं, क्योंकि इसे केवल दावा चरण में फिर से कॉल किया जा रहा है।

उदाहरण के लिए, यदि आप कुछ गणित कर रहे हैं:

test "average returns the average of a set of numbers" do
  # arrange
  numbers = [1, 2, 3, 4]
  # act
  average = numbers.average
  # assert
  # यह बुरा है
  assert_equal [1, 2, 3, 4].average, average
  # यह बेहतर है
  assert_equal 2.5, average
end

दावा चरण में फिर से [1, 2, 3, 4].average कॉल करना बुरा है, क्योंकि average लगभग कुछ भी वापस कर सकता है और वह दावा अभी भी पास होगा।

यहां, यह काफी स्पष्ट है। लेकिन यहां तक कि जब चीजें अधिक जटिल हो जाती हैं, तो सुनिश्चित करें कि आप केवल वही कोड दोबारा नहीं चला रहे हैं। अन्यथा आप केवल यह सत्यापित कर रहे हैं कि आपका मेथड कॉल किया गया था, न कि यह उस तरह से काम किया जैसा आप उम्मीद करते हैं।

आमतौर पर, उत्तर तक दूसरा रास्ता अपनाने का सबसे आसान तरीका है हाथ से उत्तर ढूंढना और इसे हार्डकोड करना। यह भंगुर हो सकता है, लेकिन यह आपके टेस्ट्स के बिना आपको एहसास हुए टूटने से बेहतर है।

तीन चरण क्यों?

यदि आप अपने टेस्ट्स को उन तीन चरणों में विभाजित करते हैं, तो आपके पास जवाब देने के लिए सरल प्रश्न होते हैं। "मुझे यह टेस्ट कैसे लिखना चाहिए?" के बजाय, आप प्रत्येक चरण पर ध्यान केंद्रित कर सकते हैं: "मुझे इस टेस्ट को कैसे सेट अप करना चाहिए?", "मैं क्या टेस्ट कर रहा हूं?", "उत्तर कैसा दिखना चाहिए?"

इन सवालों के अभी भी आसान उत्तर नहीं हो सकते हैं, लेकिन उत्तर पूरे टेस्ट के बारे में एक साथ सोचने की तुलना में बहुत आसान होंगे। और यदि आप भाग्यशाली हैं, तो आप संबंधित टेस्ट्स के बीच चरणों को साझा भी कर सकते हैं, जिससे आपका अगला टेस्ट लिखना बहुत कम दर्दनाक होगा।