আপনি কীভাবে কোনও ত্রুটির জন্য টিডিডি করতে পারেন যা কেবলমাত্র এটি ঠিক করার পরে পরীক্ষা করা যেতে পারে?


13

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

আমার সমস্যাটি হ'ল এই বাগটি কীভাবে ঠিক করা যায় তা প্রাথমিকভাবে আমার কোনও ধারণা নেই এবং আমি পরীক্ষাটি লিখতে পারার একমাত্র উপায় এটি ঠিক করার পরে fixed

একটি সাধারণ ফাংশনে যেমন let sum = (a, b) => a - bআপনি কোনও কোড লেখার আগে কেন sum(1, 2)সমান হয় না তা পরীক্ষা করে লিখতে পারেন 3

আমি যে ক্ষেত্রে বর্ণনা করছি, আমি পরীক্ষা করতে পারছি না, কারণ যাচাইকরণ কী তা আমি জানি না (জোর কী হওয়া উচিত তা আমি জানি না)।

বর্ণিত সমস্যার সমাধান:

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

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

এই সমস্যার জন্য টিডিডি পদ্ধতির কী হবে? কোড লিখার আগে কোড বাধ্যতামূলক বা beforeচ্ছিক?


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

@ কিলিয়ান ফথ: আমি প্রশ্নের শিরোনাম পরিবর্তন করে আপনার ভাল উদ্দেশ্যগুলি দেখতে পাচ্ছি, তবে আপনার সম্পাদনাটি আমার উত্তরের অকার্যকর অংশগুলি অকার্যকর করেছে। তদুপরি, আপনার নতুন শিরোনাম আইএমএইচও-র প্রশ্নের সংস্থার সাথে উপযুক্ত নয়। তাই আমি কোনও রোলব্যাক করেছি, কোনও অপরাধ হয়নি।
ডক ব্রাউন

উত্তর:


26

আমি যখন আপনাকে সঠিকভাবে বুঝতে পেরেছিলাম, আপনি কোনও সমাধান খুঁজে পাওয়ার পরেও আপনার "ভূতের চিত্র" উদাহরণের জন্য একটি নির্ভরযোগ্য স্বয়ংক্রিয় পরীক্ষা লিখতে পারবেন না , যেহেতু সঠিক আচরণ যাচাই করার একমাত্র উপায় হ'ল পর্দার দিকে তাকানো এবং কোনও ভুতের চিত্র নেই কিনা তা পরীক্ষা করা to আর কোন। এটি আমাকে আপনার মূল শিরোনামটি ভুল প্রশ্ন জিজ্ঞাসা করে। আসল প্রশ্নটি হওয়া উচিত

  • গ্রাফিকাল ইউজার ইন্টারফেসের নির্দিষ্ট আচরণটি কীভাবে স্বয়ংক্রিয়ভাবে পরীক্ষা করা যায়?

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

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

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


সাধারণ UI টেস্টিং অ-তুচ্ছ হয়; আপনি হ্যাশ একটি উত্পন্ন চিত্রটি পিন করতে পারেন, আপনি সিমুলেট / স্বয়ংক্রিয় করতে পারেন, আপনি ম্যাক্রোগুলি রেকর্ড করতে পারেন, আপনি মালিকানা সমাধান ব্যবহার করতে পারেন, আপনি ম্যানুয়াল টেস্টিং ব্যবহার করতে পারেন, পরিস্থিতি এবং আপনার প্রকল্পের জন্য কীভাবে প্রয়োজনীয় স্বয়ংক্রিয় ইউআই পরীক্ষার প্রয়োজন তা নির্ভর করে।
esoterik

1
@ এসোটেরিক: হ্যাঁ, এবং এই সমস্ত স্বয়ংক্রিয় কৌশলগুলি ত্রুটি-প্রবণ এবং ভঙ্গুর, যেমনটি আমি ইতিমধ্যে লিখেছি। আমি জানি কেবলমাত্র নন-ভঙ্গুর দৃষ্টিভঙ্গি হ'ল ম্যানুয়াল টেস্টিং।
ডক ব্রাউন

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

1
@ ম্যাক্সিমিডেপ্রে: একটি বিজ্ঞাপনের জন্য এই বিজ্ঞাপনটি খুঁজে পেয়েছে যা সমস্যার সমাধান করার চেষ্টা করে তবে তবুও নিবন্ধটি আমার উত্তরটির সাথে সাধারণভাবে একমত বলে মনে হচ্ছে।
ডক ব্রাউন

5

এই সমস্যার জন্য টিডিডি পদ্ধতির কী হবে? কোড লিখার আগে কোড বাধ্যতামূলক বা beforeচ্ছিক?

একটি উপায় হ'ল স্পাইক সমাধানের এনালগ প্রয়োগ করা ।

জেমস শোর এটিকে এভাবে বর্ণনা করেছেন:

যখন আমাদের আরও তথ্যের প্রয়োজন হয় তখন আমরা ছোট, বিচ্ছিন্ন পরীক্ষা-নিরীক্ষা করি।

মূল ধারণাটি হ'ল আপনি কী চলছে তা নির্ধারণের সময় ডিজাইনের সরঞ্জামগুলি নীচে রেখেছেন । আপনার নিজের বিয়ারিংগুলি একবার হয়ে গেলে, আপনি আবার ডিজাইনের সরঞ্জামগুলি বেছে নেবেন।

কৌশলটি: আপনি তদন্ত থেকে জ্ঞানটি আপনার প্রোডাকশন কোড বেসে ফিরিয়ে আনেন তবে আপনি কোডটি আনেন না । পরিবর্তে, আপনি আপনার শৃঙ্খলাবদ্ধ ডিজাইনের কৌশলগুলি ব্যবহার করার সময় এটি পুনরায় তৈরি করুন।

ভিন্ন ভিন্ন মানুষ ভিন্ন ভিন্ন জিনিস এর জন্য উপযোগী.

সম্পাদনা করুন:

ত্রুটিটি যদি কেবল একটি মানব চোখ দ্বারা দেখা যায় তবে আপনি কীভাবে একটি পরীক্ষা স্বয়ংক্রিয় করতে পারেন?

আমি কিছুটা আলাদা বানানের পরামর্শ দিতে চাই: "যদি পরীক্ষাটি স্বয়ংক্রিয় করা কার্যকর হয় না তবে আপনি কীভাবে একটি পরীক্ষা স্বয়ংক্রিয় করতে পারেন?"

উত্তরটি অবশ্যই "আপনি করবেন না"। পরিবর্তে, আপনার প্রয়োগকে দুটি ভাগে বিভক্ত করার চেষ্টা করুন - একটি বড় অংশ যেখানে পরীক্ষার ব্যয় কার্যকর এবং একটি ছোট অংশ যা ভাঙা খুব সহজ।

সফ্টওয়্যার ডিজাইন তৈরির দুটি উপায় রয়েছে: একটি উপায় হ'ল এটিকে এত সহজ করা যে স্পষ্টত কোনও ঘাটতি নেই - CAR Hoare

সুতরাং তৃতীয় পক্ষের কোডের সাথে কাজ করার সময়, আমাদের কাছে কোডের একটি খুব পাতলা শেল থাকবে যা তৃতীয় পক্ষের লাইব্রেরির জন্য প্রক্সি হিসাবে কাজ করে। পরীক্ষায়, আমরা সেই শেলটিকে একটি "টেস্ট ডাবল" দিয়ে প্রতিস্থাপন করি , এটি প্রোটোকল যাচাই করে না যে এটি পছন্দসই প্রভাব তৈরি করে।

আসল তৃতীয় পক্ষের কোডের সাথে আমাদের কোডগুলি সংহতকরণের পরীক্ষার জন্য, আমরা অন্যান্য কৌশলগুলির উপর নির্ভর করি (ভিজ্যুয়াল যাচাইকরণ, প্রযুক্তি সমর্থন কল, আশাবাদ ....)

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


জেমস শোর যা বলতে চাই তা আমি পছন্দ করি। আমি বর্তমানে www.letcodejavascript.com স্ক্রিনকাস্ট অনুসরণ করছি এবং আমি অনেক কিছু শিখছি। আপনি যে লিঙ্কগুলিতে আমাকে নির্দেশ করেছেন আমি সেগুলি পড়ব।
ম্যাক্সিমিডেপ্রে

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

0

গ্রহণযোগ্যতা পরীক্ষার (বৈশিষ্ট্য / ব্যবসায়িক কাজের প্রবাহ কেন্দ্রিক পরীক্ষাগুলি) সম্মতিতে ইউআই / জিইউআইয়ের কাছাকাছি পরীক্ষাটি কিছুটা আরও ভাল করা যেতে পারে a

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

আপনার অবস্থার সাথে বিশেষভাবে যে অংশটি সহায়তা করবে সেটিকে হ'ল পেজ অবজেক্ট মডেল ( https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html ) বলে something এটি পদ্ধতি / ইভেন্ট / শ্রেণি সদস্যদের নাম দ্বারা কোনও কোডে রান-টাইম জিইউআইয়ের স্পষ্ট ম্যাপিং অর্জন করে।

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

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


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

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

0

একটি ভূতের চিত্র দেখতে কেমন? যদি আপনি একটি পরিচিত রঙের একটি ডামি ইউআই তৈরি করেন, যেখানে আপনি আপনার ড্রাগযোগ্য উপাদানটি রেখেছেন? কোনও ভূতের চিত্র থাকলে সেখানে কোনও নির্দিষ্ট রঙ উপস্থিত থাকত?

তারপরে পরীক্ষাটি ভূতের চিত্রের রঙের অনুপস্থিতির জন্য পরীক্ষা করতে পারে।

এই ধরনের পরীক্ষা যুক্তিসঙ্গত টেকসই এবং করণীয় হবে।


করণীয় - হ্যাঁ টেকসই - নির্ভর করে। আপনার ইউআই এর রঙ / থিম পরিবর্তন করা আপনার পরীক্ষা / গুলি ভেঙে দিতে পারে, এটি আমার পক্ষে খুব বেশি টেকসই মনে হয় না।
শান বার্টন

1
আপনি পুরো UI পরীক্ষা করবেন না। আপনি ড্রাগ-এন-ড্রপ উপাদানটির জন্য একটি ডামি ইউআই তৈরি করবেন।
এসবেন স্কোভ পেডারসেন

আপনি যে পরামর্শ দিচ্ছেন তা কীভাবে সম্পাদন করবেন তা আমি নিশ্চিত নই। আমার ক্ষেত্রে একটি ভূতের চিত্রটি সেই উপাদানটির একটি আধা-অস্বচ্ছ প্রতিরূপ হবে যা টেনে আনা হচ্ছে। টানুন এবং ড্রপ হওয়ার সময় ভূত চিত্রটি সর্বদা কার্সার অনুসরণ করছে।
ম্যাক্সিমিডেপ্রে

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