আরএসপেক কখন ব্যবহার করবেন?


447

উদাহরণস্বরূপ ভেরিয়েবল সেট করার জন্য আমি ব্লকগুলির আগে ব্যবহার করার প্রবণতা রাখি। আমি তখন আমার উদাহরণগুলিতে সেই পরিবর্তনগুলি ব্যবহার করি। আমি সম্প্রতি এসেছি let()। আরএসপেক ডক্স অনুসারে এটি অভ্যস্ত

... একটি স্মৃতিচারণকারী সহায়ক পদ্ধতি সংজ্ঞায়িত করতে। মান একই উদাহরণে একাধিক কলগুলিতে ক্যাশে হবে তবে উদাহরণগুলিতে নয়।

ব্লকের আগে উদাহরণ পরিবর্তনগুলি ব্যবহার করা থেকে এটি কীভাবে আলাদা? এবং আপনি কখন let()বনাম ব্যবহার করা উচিত before()?


1
ব্লকগুলি অলসভাবে মূল্যায়ন করা যাক, যখন প্রতিটি উদাহরণের আগে ব্লকগুলি চলার আগে (সেগুলি সামগ্রিক ধীর হয়)। ব্লকগুলির আগে ব্যবহার করা ব্যক্তিগত পছন্দের উপর নির্ভর করে (কোডিং স্টাইল, মক / স্টাব ...)। ব্লকগুলি সাধারণত পছন্দ করা হয়। আপনি লেট সম্পর্কে
নেশা জোরিক

আগে হুকের ক্ষেত্রে ইনস্ট্যান্স ভেরিয়েবল সেট করা ভাল অনুশীলন নয়। পরীক্ষা করে দেখুন betterspecs.org
অ্যালিসন

উত্তর:


604

আমি বেশ letকয়েকটি কারণে সর্বদা উদাহরণের পরিবর্তনশীলকে পছন্দ করি :

  • রেফারেন্স পেলে ইনস্ট্যান্স ভেরিয়েবলগুলি অস্তিত্বের মধ্যে বসন্ত। এর অর্থ হ'ল যদি আপনি উদাহরণের পরিবর্তনশীলটির বানানটি ফ্যাট করেন তবে একটি নতুন তৈরি হবে এবং এতে আরম্ভ হবেnil , যা সূক্ষ্ম বাগ এবং মিথ্যা ধনাত্মক হতে পারে। যেহেতু letএকটি পদ্ধতি তৈরি করে, আপনি একটি পাবেনNameError যখন এটি ভুল বানান করেন তখন আপনি এটি পাবেন যা আমি পছন্দনীয় বলে মনে করি। এটি রিফ্যাক্টর চশমাগুলিকেও সহজ করে তোলে।
  • একজন before(:each)প্রতিটি উদাহরণের আগে হুক চলবে, যদিও উদাহরণটি হুকটিতে সংজ্ঞায়িত কোনও ইনস্ট্যান্স ভেরিয়েবল ব্যবহার করে না। এটি সাধারণত কোনও বড় বিষয় নয়, তবে যদি উদাহরণের চলকটির সেটআপটি দীর্ঘ সময় নেয় তবে আপনি চক্রটি নষ্ট করছেন। দ্বারা সংজ্ঞায়িত পদ্ধতির জন্যlet , উদাহরণ কোডটি কল করলেই সূচনা কোডটি চালিত হয়।
  • উদাহরণস্বরূপ রেফারেন্সিং সিনট্যাক্সটি পরিবর্তন না করে আপনি একটি স্থানীয় ভেরিয়েবল থেকে উদাহরণস্বরূপ সরাসরি একটি লেটে পরিণত করতে পারেন। আপনি যদি কোনও উদাহরণ ভেরিয়েবলের সাথে রিফ্যাক্টর করেন তবে আপনাকে উদাহরণটিতে কীভাবে বস্তুর রেফারেন্স করতে হবে তা পরিবর্তন করতে হবে (উদাঃ একটি যোগ করুন@ )।
  • এটি কিছুটা সাবজেক্টিভ, তবে মাইক লুইস যেভাবে উল্লেখ করেছেন, আমি মনে করি এটি পড়তে আরও সহজ করে তোলে। letআমার itব্লকটিকে সুন্দর এবং সংক্ষিপ্ত রাখার সাথে আমার সমস্ত নির্ভরশীল অবজেক্টগুলি সংজ্ঞায়িত করার এবং সংস্থার পছন্দ করি ।

সম্পর্কিত লিঙ্কটি এখানে পাওয়া যাবে: http://www.betterspecs.org/#let


2
আপনি যে প্রথম সুবিধাটি উল্লেখ করেছেন তা আমি সত্যিই পছন্দ করি তবে তৃতীয়টি সম্পর্কে আপনি কি আরও কিছু ব্যাখ্যা করতে পারেন? এখনও অবধি আমি যে উদাহরণগুলি দেখেছি (মংগয়েড চশমা: github.com/mongoid/mongoid/blob/master/spec/functional/mongoid/… ) একক লাইন ব্লক ব্যবহার করে এবং আমি দেখতে পাচ্ছি না যে "@" কীভাবে এটি তৈরি করে না পড়া সহজ।
প্রেরণ-ইল

6
যেমনটি আমি বলেছি, এটি কিছুটা সাবজেক্টিভ, তবে letনির্ভর করে সমস্ত নির্ভরযোগ্য অবজেক্টের সংজ্ঞা দিতে এবং before(:each)প্রয়োজনীয় কনফিগারেশন বা উদাহরণগুলির দ্বারা প্রয়োজনীয় কোনও মক / স্টাব সেটআপ করতে ব্যবহার করা আমার পক্ষে সহায়ক বলে মনে হচ্ছে। আমি এই সব হুক আগে একটি বড় এটি পছন্দ। এছাড়াও, let(:foo) { Foo.new }তারপর (বিন্দু থেকে এবং আরো) কম সশব্দ before(:each) { @foo = Foo.new }। আমি এটি কীভাবে ব্যবহার করি তার একটি উদাহরণ এখানে দেওয়া হয়েছে: github.com/myronmarston/vcr/blob/v1.7.0/spec/vcr/util/…
মাইরন

উদাহরণস্বরূপ ধন্যবাদ, এটি সত্যই সহায়তা করেছিল।
প্রেরণ-ইল

3
অ্যান্ড্রু গ্রিম: সত্য, তবে সতর্কতাগুলি প্রচুর শব্দ করতে পারে (অর্থাত রত্নগুলি ব্যবহার করে যা সতর্কতা-মুক্ত নয় run অধিকন্তু, আমি NoMethodErrorসতর্কতা পেতে পছন্দ করা পছন্দ করি তবে ওয়াইএমএমভি।
মাইরন মার্সটন

1
@ জওয়ান 22২২: আপনি সম্ভবত একটি উদাহরণ লিখে শুরু করতে পারেন, যা পরে foo = Foo.new(...)এবং পরে ব্যবহারকারীদের fooরয়েছে। পরে, আপনি একই উদাহরণ গোষ্ঠীতে একটি নতুন উদাহরণ লিখুন Fooযা একই পদ্ধতিতে ইনস্ট্যান্টিয়েটেডেরও প্রয়োজন । এই সময়ে, আপনি সদৃশটি অপসারণ করতে রিফ্যাক্টর করতে চান to আপনি foo = Foo.new(...)আপনার উদাহরণগুলি থেকে লাইনগুলি সরাতে পারেন এবং let(:foo) { Foo.new(...) }উদাহরণগুলি কীভাবে ব্যবহার করবেন তা পরিবর্তন করে ডাব্লু / ও দিয়ে এটি প্রতিস্থাপন করতে পারেন foo। আপনি যদি আপনার কাছে রিফ্যাক্টর করেন তবে এগুলি before { @foo = Foo.new(...) }থেকেও উদাহরণগুলিতে উল্লেখগুলি আপডেট fooকরতে হবে @foo
মাইরন মার্সটন

82

দৃষ্টান্ত ভেরিয়েবল এবং ব্যবহার মধ্যে পার্থক্য let()যে let()হয় অলস-মূল্যায়ন । এই যে মানেlet() পদ্ধতিটি প্রথমবারের জন্য পরিচালিত হয় ততক্ষণ মূল্যায়ন করা হয় না।

beforeএবং এর মধ্যে পার্থক্য letহ'ল let()আপনাকে একটি 'ক্যাসকেডিং' স্টাইলে ভেরিয়েবলের একটি গ্রুপ নির্ধারণ করার একটি দুর্দান্ত উপায় দেয়। এটি করে, কোডটি সরল করে অনুমানটি কিছুটা ভাল দেখায়।


1
আমি দেখছি, এটা কি আসলেই সুবিধা? কোডটি প্রতিটি উদাহরণের জন্য নির্বিশেষে চালিত হচ্ছে।
প্রেরণ-ইল

2
আইএমও পড়া সহজ, এবং প্রোগ্রামিং ভাষাগুলিতে পঠনযোগ্যতা একটি বিশাল উপাদান।
মাইক লুইস

4
সেন্থিল - আপনি লেট () ব্যবহার করার সময় এটি প্রতিটি উদাহরণে অগত্যা চলমান নয়। এটি অলস, সুতরাং এটি কেবল রেফারেন্স থাকলে চালিত হবে। সাধারণত এটি বলার অপেক্ষা রাখে না কারণ একটি উদাহরণ গোষ্ঠীর বক্তব্যটি একটি সাধারণ প্রসঙ্গে বেশ কয়েকটি উদাহরণ চালিত করে।
ডেভিড চেলিমস্কি

1
তাহলে এর অর্থ কি letপ্রতিবার মূল্যায়নের জন্য যদি আপনার কিছু প্রয়োজন হয় তবে আপনার ব্যবহার করা উচিত নয় ? উদাহরণস্বরূপ, প্যারেন্ট মডেলটিতে কিছু আচরণ শুরু করার আগে আমার একটি শিশু মডেলটি ডাটাবেসে উপস্থিত থাকতে হবে। আমি অগত্যা পরীক্ষায় সেই শিশু মডেলটিকে উল্লেখ করছি না, কারণ আমি পিতামাতার মডেলগুলির আচরণটি পরীক্ষা করছি। এই মুহূর্তে আমি let!পরিবর্তে পদ্ধতিটি ব্যবহার করছি , তবে সম্ভবত এই সেটআপটি রাখা আরও স্পষ্ট হবে before(:each)?
Gar

2
@gar - আমি একটি কারখানা (যেমন ফ্যাক্টরিগার্ল) ব্যবহার করব যা আপনি পিতামাতাকে তাত্ক্ষণিক ব্যবহারের সময় সেই প্রয়োজনীয় শিশু সমিতি তৈরি করতে দেয়। আপনি যদি এটি এভাবে করেন তবে আপনি লেট () বা একটি সেটআপ ব্লক ব্যবহার করেন কিনা তা আসলেই কিছু আসে যায় না। আপনার সাব-কনটেক্সটগুলিতে প্রতিটি পরীক্ষার জন্য যদি আপনাকে সমস্ত কিছু ব্যবহার না করার দরকার হয় তবে লেটটি () দুর্দান্ত। সেটআপ প্রত্যেকের জন্য প্রয়োজনীয় যা হওয়া উচিত।
হার্মোন

17

লেট () ব্যবহার করার জন্য আমি আমার আরএসপেক টেস্টগুলিতে ইনস্ট্যান্স ভেরিয়েবলের সমস্ত ব্যবহারকে সম্পূর্ণরূপে প্রতিস্থাপন করেছি। আমি একটি বন্ধুর জন্য একটি দ্রুত উদাহরণ লিখেছি যিনি এটি একটি ছোট আরএসপেক ক্লাস শেখানোর জন্য ব্যবহার করেছিলেন: http://ruby-lambda.blogspot.com/2011/02/agile-rspec-with-let.html

যেমন অন্যান্য উত্তরগুলির কিছু এখানে বলেছে, আসুন () অলসভাবে মূল্যায়ন করা হয় সুতরাং এটি কেবলমাত্র লোডিংয়ের প্রয়োজনীয়তাগুলি লোড করবে। এটি অনুমানটি DRYs করে এবং আরও পাঠযোগ্য করে তোলে। উত্তরাধিকার সূত্রে রত্ন রত্নের স্টাইলে আমি আসলে আমার কন্ট্রোলারে আরএসপিকে লেট () কোডটি ব্যবহার করতে পোর্ট করেছি। http://ruby-lambda.blogspot.com/2010/06/stealing-let-from-rspec.html

অলস মূল্যায়নের পাশাপাশি, অন্য সুবিধাটি হ'ল, অ্যাক্টিভসপোর্ট :: কনসার্ন এবং লোড-ইন-স্পিচ-ইন স্পেক / সাপোর্ট / আচরণের সাথে মিলিত হয়ে আপনি নিজের অ্যাপ্লিকেশনের জন্য নির্দিষ্ট নিজের স্পেস মিনি-ডিএসএল তৈরি করতে পারেন। আমি র্যাক এবং বিশ্রামের সংস্থানগুলির বিরুদ্ধে পরীক্ষার জন্য লিখেছি written

আমি যে কৌশলটি ব্যবহার করি তা হ'ল ফ্যাক্টরি-সবকিছু (মেশিনিস্ট + ফোরজি / ফ্যাকারের মাধ্যমে)। তবে, উদাহরণস্বরূপ গোষ্ঠীগুলির পুরো সেটগুলির জন্য প্রিললোড কারখানার পূর্বে (: প্রতিটি) ব্লকের সাথে মিশ্রণে এটি ব্যবহার করা সম্ভব, চশমাগুলি আরও দ্রুত চালিত হতে পারে: http://makandra.com/notes/770-taking- गैर-সুবিধা -of-rspec-s-দিন-ইন-সামনে-ব্লক


আরে হো-শেং, আমি এই প্রশ্ন জিজ্ঞাসার আগে আপনার বেশ কয়েকটি ব্লগ পোস্ট পড়েছিলাম। আপনার # spec/friendship_spec.rbএবং # spec/comment_spec.rbউদাহরণ সম্পর্কিত, আপনি কি মনে করেন না তারা এটিকে কম পাঠযোগ্য করে তোলে? আমি জানি না usersকোথা থেকে এসেছে এবং আরও গভীর খননের প্রয়োজন হবে।
প্রেরণ-ইল

প্রথম ডজন বা তাই লোকেরা আমি ফর্ম্যাটটি সকলের কাছে দেখিয়েছি এটি আরও বেশি পঠনযোগ্য বলে খুঁজে পেয়েছে এবং তাদের মধ্যে কয়েকজন এটি দিয়ে লেখা শুরু করেছিলেন। লেট () ব্যবহার করে আমি এখন যথেষ্ট স্পেস কোড পেয়েছি যে আমি সেগুলির কিছু সমস্যার মধ্যেও চলেছি। আমি নিজেকে উদাহরণটিতে যাচ্ছি এবং অভ্যন্তরীণ উদাহরণ গোষ্ঠী থেকে শুরু করে নিজেকে ব্যাক আপ করে দেখছি। এটি একটি উচ্চ মেটা-প্রোগ্রামযোগ্য পরিবেশ ব্যবহার করার মতো দক্ষতা।
হো-শেং Hsiao

2
আমি যে বৃহত্তম গোচাটি চালিয়েছি তা হ'ল ঘটনাক্রমে let subject সাবজেক্টের পরিবর্তে {} ব্যবহার করা} সাবজেক্ট () লেট (: সাবজেক্ট) থেকে আলাদাভাবে সেট আপ করা হয়েছে তবে লেট (: সাবজেক্ট) এটিকে ওভাররাইড করবে।
হো-শেং Hsiao

1
আপনি যদি কোডটিতে "ড্রিলিং" যেতে দিতে পারেন তবে আপনি লেট () ঘোষণা দিয়ে একটি কোড স্ক্যান করতে পারবেন যা অনেক বেশি দ্রুত find কোডটি এম্বেড থাকা @ ভেরিয়েবলগুলি খুঁজে পাওয়ার চেয়ে কোড স্ক্যান করার সময় লেট () ঘোষণাগুলি নেওয়া সহজ। @ ভেরিয়েবলগুলি ব্যবহার করে, আমার কোনও ভাল "আকৃতি" নেই যার জন্য লাইনগুলি ভেরিয়েবলগুলি নির্ধারিত করে এবং কোন রেখাগুলি ভেরিয়েবলগুলি পরীক্ষা করার জন্য উল্লেখ করে। লেট () ব্যবহার করে সমস্ত অ্যাসাইনমেন্ট লেট () দিয়ে সম্পন্ন হয় যাতে আপনার ঘোষণাপত্রগুলি হ'ল অক্ষরের আকারের দ্বারা আপনি "তাত্ক্ষণিকভাবে" জানতে পারেন।
হো-শেং Hsiao 20'11

1
উদাহরণস্বরূপ ভেরিয়েবলগুলি তুলনামূলক সহজতর হওয়া সম্পর্কে আপনি একই যুক্তি তৈরি করতে পারেন, বিশেষত যেহেতু কিছু সম্পাদক যেমন খনি (gedit) হাইলাইট উদাহরণ ভেরিয়েবলগুলি। আমি let()গত কয়েক দিন ব্যবহার করেছি এবং ব্যক্তিগতভাবে আমি কোনও পার্থক্য দেখতে পাচ্ছি না, মাইরনের উল্লিখিত প্রথম সুবিধা ব্যতীত। এবং আমি ছেড়ে দেওয়া এবং কী করব না সম্পর্কে এতটা নিশ্চিত নই, কারণ সম্ভবত আমি অলস এবং আমি অন্য কোনও ফাইল না খোলায় কোডটি সামনে দেখতে পছন্দ করি। তোমার মন্তব্যের জন্য ধন্যবাদ.
-এ প্রেরণ-ইল পাঠানো হয়েছে

13

এটা তোলে মনে রাখা যে গুরুত্বপূর্ণ এলইটি হয় অলস মূল্যায়ন এবং নির্বাণ না এটা পার্শ্ব প্রতিক্রিয়া পদ্ধতি অন্যথায় তুমি কি পরিবর্তিত করতে সক্ষম হবে এলইটি করতে : (প্রতিটি) আগের সহজে। আপনি লেট ব্যবহার করতে পারেন ! পরিবর্তে দিন যাতে এটি প্রতিটি দৃশ্যকল্প সামনে মূল্যায়ন করা হয়।


8

সাধারণভাবে, let()এটি একটি দুর্দান্ত সিনট্যাক্স এবং এটি @nameপুরো জায়গা জুড়ে আপনাকে চিহ্নগুলি টাইপ করে সংরক্ষণ করে। তবে, সাবধান! আমি let()সূক্ষ্ম বাগগুলি (বা কমপক্ষে মাথা স্ক্র্যাচিং) এরও পরিচয় করিয়ে দিয়েছি কারণ ভেরিয়েবলটি ব্যবহার করার চেষ্টা না করা অবধি সত্যই উপস্থিত নেই ... গল্পের চিহ্নটি বলুন: যদি ভেরিয়েবলটি সঠিক হয় তা দেখার putsপরে যদি একটি যোগ করা যায় তবে let()একটি স্পেসকে অনুমতি দেয় পাস, কিন্তু ছাড়াputs অনুমানটি ব্যর্থ হয় - আপনি এই সূক্ষ্মতা খুঁজে পেয়েছেন।

আমি এটিও পেয়েছি যে let()সব পরিস্থিতিতে ক্যাশে বলে মনে হচ্ছে না! আমি আমার ব্লগে এটি লিখেছিলাম: http://technicaldebt.com/?p=1242

হয়তো এটা শুধু আমার হয়?


9
letসর্বদা একটি উদাহরণের সময়কালের জন্য মানকে স্মরণ করে। এটি একাধিক উদাহরণ জুড়ে মানটিকে স্মরণ করে না। before(:all)বিপরীতে, একাধিক উদাহরণে আপনাকে একটি প্রাথমিক ভেরিয়েবল পুনরায় ব্যবহার করতে দেয়।
মাইরন মার্সটন

2
আপনি যদি লেট ব্যবহার করতে চান (যেমনটি এখন সেরা অনুশীলন বলে মনে হয়) তবে এখনই ইনস্ট্যান্ট করার জন্য একটি নির্দিষ্ট পরিবর্তনশীল প্রয়োজন, let!এটিই এর জন্য ডিজাইন করা হয়েছে। relishapp.com/rspec/rspec-core/v/2-6/docs/helper-methods/…
জ্যাকব

6

আসুন এটির মূলত একটি প্রক হিসাবে কার্যকর হয়। এটির ক্যাশেড

একটি গ্যাচা আমি সাথে সাথে খুঁজে পেয়েছি ... একটি স্পষ্ট ব্লকে যা পরিবর্তনের মূল্যায়ন করছে।

let(:object) {FactoryGirl.create :object}

expect {
  post :destroy, id: review.id
}.to change(Object, :count).by(-1)

আপনার কল করার বিষয়ে নিশ্চিত হওয়া দরকার letআপনার প্রত্যাশিত ব্লকের বাইরে । অর্থাৎ আপনি FactoryGirl.createআপনার লেট ব্লকে কল করছেন । আমি সাধারণত অবজেক্টটি স্থির করে যাচাই করে এটি করি।

object.persisted?.should eq true

অন্যথায় যখন let ব্লকটি প্রথমবার বলা হয় তখন অলস তাত্ক্ষণিকতার কারণে ডাটাবেসে পরিবর্তন আসলে ঘটবে।

হালনাগাদ

শুধু একটি নোট যোগ করুন। খেলে সাবধানতা অবলম্বন করুনকোড গল্ফ বা এই ক্ষেত্রে আরএসপেক গল্ফ এই উত্তরটি সহ ।

এই ক্ষেত্রে, আমাকে কেবল এমন কিছু পদ্ধতি কল করতে হবে যাতে অবজেক্ট সাড়া দেয়। সুতরাং আমি প্রার্থনা_.persisted? _ পদ্ধতিরটিকে সত্য হিসাবে চিহ্নিত করছি। আমি যা করার চেষ্টা করছি তা হ'ল অবজেক্টটি ইনস্ট্যান্ট করা। আপনি খালি কল করতে পারেন? না শিল? খুব। বিন্দুটি পরীক্ষা নয় বরং এটি কল করে অবজেক্টটিকে ওটি লাইফ করে আনা।

সুতরাং আপনি চুল্লী করতে পারবেন না

object.persisted?.should eq true

হতে

object.should be_persisted 

যেহেতু বস্তুটি তাত্ক্ষণিকভাবে চালিত হয়নি ... এটি অলস। :)

আপডেট 2

লিভারেজ যাক! তাত্ক্ষণিক অবজেক্ট তৈরির জন্য বাক্য গঠন , যা পুরোপুরি এই সমস্যাটি এড়ানো উচিত। নোট করুন যদিও এটি অ-ব্যঞ্জড লেটের অলসতার উদ্দেশ্যটিকে অনেকটাই পরাজিত করবে।

এছাড়াও কিছু ক্ষেত্রে আপনি সম্ভবত বিষয়বস্তু সিনট্যাক্সটি উপস্থাপনের পরিবর্তে এটির অতিরিক্ত বিকল্পগুলি দিতে পারেন synt

subject(:object) {FactoryGirl.create :object}

2

জোসেফের কাছে দ্রষ্টব্য - আপনি যদি কোনও ডাটাবেস অবজেক্ট তৈরি করে থাকেন তবে before(:all)সেগুলি কোনও লেনদেনে ধরা পড়বে না এবং আপনার পরীক্ষার ডাটাবেসে ক্রাফ্ট ছেড়ে যাওয়ার সম্ভাবনা অনেক বেশি। ব্যবহারbefore(:each)পরিবর্তে করুন।

লেট এবং এর অলস মূল্যায়নের ব্যবহারের অন্য কারণটি হ'ল আপনি একটি জটিল অবজেক্ট নিতে পারেন এবং স্বতন্ত্র টুকরো টুকরো টুকরো পরীক্ষা করে দেখতে পারেন প্রসঙ্গে, যেমন এই খুব স্বীকৃত উদাহরণ হিসাবে:

context "foo" do
  let(:params) do
     { :foo => foo,  :bar => "bar" }
  end
  let(:foo) { "foo" }
  it "is set to foo" do
    params[:foo].should eq("foo")
  end
  context "when foo is bar" do
    let(:foo) { "bar" }
    # NOTE we didn't have to redefine params entirely!
    it "is set to bar" do
      params[:foo].should eq("bar")
    end
  end
end

1
+1 এর আগে (: সমস্ত) ত্রুটিগুলি আমাদের বিকাশকারীদের অনেক দিনের অপচয় করে।
মাইকেল ডুরান্ট

1

ডিফল্টরূপে "আগে" বোঝায় before(:each)। রিস্পেক বুক, কপিরাইট 2010, পৃষ্ঠা 228 রেফ করুন।

before(scope = :each, options={}, &block)

আমি before(:each)কল না করে প্রতিটি উদাহরণ গোষ্ঠীর জন্য কিছু ডেটা বীজ করতে ব্যবহার করিlet"এটি" ব্লকে ডেটা তৈরির জন্য পদ্ধতিটি । এই ক্ষেত্রে "এটি" ব্লক কম কোড।

আমি letকিছু উদাহরণে কিছু ডেটা চাইব তবে অন্যদের নয় use

"এটি" ব্লকগুলি ডিআরওয়াই করার জন্য আগে এবং আগে উভয়ই দুর্দান্ত।

কোনও বিভ্রান্তি এড়াতে, "লেট" এর মতো নয় before(:all)। "আসুন" প্রতিটি উদাহরণ ("এটি") এর জন্য এর পদ্ধতি এবং মানটির পুনরায় মূল্যায়ন করে তবে একই উদাহরণে একাধিক কলগুলিতে মানটিকে ক্যাশে করে। আপনি এটি সম্পর্কে এখানে আরও পড়তে পারেন: https://www.relishapp.com/rspec/rspec-core/v/2-6/docs/helper-methods/let-and-let


1

এখানে ভিন্নমত পোষণকারী কণ্ঠস্বর: আরএসপেকের 5 বছর পরে আমি letখুব বেশি পছন্দ করি না ।

1. অলস মূল্যায়ন প্রায়শই পরীক্ষার সেটআপটিকে বিভ্রান্ত করে তোলে

যখন সেটআপে ঘোষিত কিছু জিনিস বাস্তবে রাষ্ট্রকে প্রভাবিত করে না, যখন অন্যগুলি সেটআপ নিয়ে तर्क করা কঠিন হয়ে পড়ে।

অবশেষে, হতাশার কারণে কেউ কেবল তার অবিশ্বাস্য কাজটি করার জন্য (অলস মূল্যায়ন ছাড়াই একই জিনিস) পরিবর্তিত letহয় let!। যদি এটি তাদের পক্ষে কাজ করে তবে একটি নতুন অভ্যাসের জন্ম হয়: যখন কোনও পুরানো স্যুটটিতে একটি নতুন স্পিক যুক্ত হয় এবং এটি কার্যকর হয় না, লেখক প্রথম জিনিসটি এলোমেলো letকলগুলিতে bangs যোগ করার চেষ্টা করেন ।

খুব শীঘ্রই সমস্ত কর্মক্ষমতা সুবিধা চলে গেছে।

২.আরএসপেক ব্যবহারকারীদের জন্য বিশেষ সিনট্যাক্স অস্বাভাবিক

আমি বরং রুপিকে আমার দলের কাছে আরএসপেকের কৌশলগুলির চেয়ে শিখিয়ে দেব। ইনস্ট্যান্স ভেরিয়েবল বা পদ্ধতি কলগুলি এই প্রকল্পে এবং অন্যদের সর্বত্র দরকারী, letবাক্য গঠনটি কেবল আরএসপিএকেই কার্যকর হবে।

৩. "সুবিধাগুলি" আমাদের সহজেই ভাল ডিজাইনের পরিবর্তনগুলি উপেক্ষা করতে দেয়

let()ব্যয়বহুল নির্ভরতাগুলির জন্য ভাল যা আমরা বারবার তৈরি করতে চাই না। এটির সাথেও জুড়ি ভালsubject মাল্টি-আর্গুমেন্ট পদ্ধতির পুনরাবৃত্তি কলগুলি শুকিয়ে দেওয়ার জন্য আপনাকে জুড়ে দেয়

ব্যয়বহুল নির্ভরতা অনেক সময় পুনরাবৃত্তি হয় এবং বড় স্বাক্ষরযুক্ত পদ্ধতিগুলি উভয় পয়েন্ট যেখানে আমরা কোডটি আরও ভাল করতে পারি:

  • সম্ভবত আমি একটি নতুন বিমূর্ততা প্রবর্তন করতে পারি যা আমার কোডের বাকী অংশ থেকে নির্ভরতা পৃথক করে (যার অর্থ কম পরীক্ষার প্রয়োজন হবে)
  • হয়তো পরীক্ষার অধীনে কোডটি খুব বেশি করছে
  • সম্ভবত আমার আদিমগুলির দীর্ঘ তালিকার পরিবর্তে স্মার্ট অবজেক্টগুলি ইনজেকশন করা দরকার
  • জিজ্ঞাসা-জিজ্ঞাসা করার লঙ্ঘন হতে পারে
  • সম্ভবত ব্যয়বহুল কোডটি দ্রুত তৈরি করা যেতে পারে (বিরল - অকাল অপ্টিমাইজেশান থেকে সাবধান থাকুন)

এই সমস্ত ক্ষেত্রে, আমি আরএসপেক ম্যাজিকের প্রশংসনীয় বালামের সাহায্যে কঠিন পরীক্ষার লক্ষণগুলিকে সম্বোধন করতে পারি, বা কারণটির সমাধান করার চেষ্টা করতে পারি। আমি মনে করি যে আমি গত কয়েক বছর অনেকটা আগের দিকে ব্যয় করেছি এবং এখন আমি আরও ভাল কোড চাই।

মূল প্রশ্নের উত্তর দেওয়ার জন্য: আমি পছন্দ না করি তবে আমি এখনও ব্যবহার করি না let। আমি এটি বেশিরভাগ দলের বাকী স্টাইলের সাথে মানিয়ে নিতে ব্যবহার করি (মনে হয় বিশ্বের বেশিরভাগ রেল প্রোগ্রামাররা এখন তাদের আরএসপেক ম্যাজিকের গভীরে চলে গেছে যাতে এটি প্রায়শই হয়)। কখনও কখনও আমি এটি ব্যবহার করি যখন আমি এমন কোনও কোডে একটি পরীক্ষা যুক্ত করি যা আমার নিয়ন্ত্রণ রাখে না, বা আরও ভাল বিমূর্ততায় রিফ্যাক্টর করার সময় পান না: অর্থাত্ যখন ব্যথানাশক থাকে তখনই বিকল্প হয়।


0

আমি ব্যবহার করি let প্রসঙ্গগুলি ব্যবহার করে আমার API টিতে আমার HTTP 404 টি প্রতিক্রিয়া পরীক্ষা করতে ।

সংস্থান তৈরি করতে, আমি ব্যবহার করি let!। তবে রিসোর্স আইডেন্টিফায়ার সঞ্চয় করতে, আমি ব্যবহার করি let। এটি দেখতে কেমন লাগে তা একবার দেখুন:

let!(:country)   { create(:country) }
let(:country_id) { country.id }
before           { get "api/countries/#{country_id}" }

it 'responds with HTTP 200' { should respond_with(200) }

context 'when the country does not exist' do
  let(:country_id) { -1 }
  it 'responds with HTTP 404' { should respond_with(404) }
end

এটি চশমাগুলি পরিষ্কার এবং পঠনযোগ্য রাখে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.