আমার কি সব পরীক্ষা করার দরকার আছে?

Question

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

স্থির পৃষ্ঠাগুলি সহ আমার আবেদনের প্রতিটি অংশের পরীক্ষা করা কি প্রয়োজনীয় ?

Comments

এটি সত্যই রেলের প্রশ্নে জঞ্জাল নয়। এটি আরও একটি টিডিডি প্রশ্ন।

— জন স্ট্রেয়ার

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

— pdr

কোনও কারণে, এই প্রশ্নটি আমাকে ক্যাপ্টেন নেরোর চিৎকার করে একটি চিত্রের ম্যাক্রো পোস্ট করতে চাইছে "টেস্টিং সব !!!"

— ম্যাসন হুইলার

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

— জেডজেআর

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

— ইভান প্লেস

Answer 1

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

সুতরাং, এটি মাথায় রেখে, একটি স্ট্যাটিক পৃষ্ঠার আচরণ কী এবং ইন্টারফেসটি কী?

আমার প্রথম প্রতিক্রিয়া হবে "কিছুই নয়" এবং "কোনওটিই নয়"।

Comments

স্ট্যাটিক পৃষ্ঠাগুলির জন্য কোনও পরীক্ষা নেই?

— মাত্তেও পাগলিয়াজি

ডিজাইনের বিষয়ে টিডিডি এক ডিগ্রি পর্যন্ত। তবে আপনার এখনও একটি স্থাপত্য প্রয়োজন। কোনও আর্কিটেকচার মাথায় না রেখে, একাধিক পরীক্ষার মধ্য দিয়ে কীভাবে কেউ জৈবিকভাবে বৃদ্ধি পাবে তা কল্পনা করা কঠিন।

— রবার্ট হার্ভে

@ ম্যাটটিওপাগলিয়াজি স্ট্যাটিক পৃষ্ঠাগুলি অ্যাক্সেসযোগ্য তা নিশ্চিত করার জন্য পরীক্ষার স্তরের উপর নির্ভর করে (ইউনিট টেস্ট / ইন্টিগ্রেশন টেস্ট / ইত্যাদি), সম্ভবত এক বা দুটি। তবে এটি ইউনিট পরীক্ষার জন্য খুব উচ্চ-স্তরের।

— ইজকাটা

পছন্দ করেছেন আমি বলেছিলাম স্ট্যাটিক পৃষ্ঠাগুলি পরীক্ষা করবেন না।

— জন স্ট্রেয়ার

@ জোনস্ট্রায়ার: ডিজি'র ডিজাইনের জন্য কিছু জাদুকর অমৃত হিসাবে টিডিডি রাখার ঝোঁক রয়েছে; আপনারা যা বোঝাতে চেয়েছিলেন তা না হলে আমি ক্ষমা চাই। :)

— রবার্ট হার্ভে

Answer 2

এটি সর্বদা ব্যয়-বেনিফিট বিশ্লেষণ। বৈশিষ্ট্যটি ভাঙার জন্য আপনার কী ব্যয় হয়? যদি ব্যয় বেশি হয়, তবে ভাল এবং পুঙ্খানুপুঙ্খভাবে পরীক্ষা করুন। যদি খরচ কম হয় তবে হালকাভাবে পরীক্ষা করুন বা মোটেও নয়।

সময়-থেকে-বাজারে বিবেচনার জন্য ব্যয়ও রয়েছে। পুরোপুরি কার্যকর বৈশিষ্ট্য সরবরাহ করার চেয়ে দেরী হওয়ার চেয়ে বেশিরভাগ কাজের বৈশিষ্ট্য সরবরাহ করা আপনার পক্ষে ভাল for

সাধারণ আইএমওতে এই প্রশ্নের উত্তর দেওয়া প্রায় অসম্ভব।

আমি মনে করি যে ক্ষেত্রে কিছু বৈশিষ্ট্য যা আপনি প্রাথমিকভাবে বুঝতে পেরেছিলেন তার থেকে বেশি গুরুত্বপূর্ণ হয়ে ওঠার ক্ষেত্রে এটির পরীক্ষার ক্ষমতা সংরক্ষণ করা আরও গুরুত্বপূর্ণ।

Comments

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

— গর্ডন গুস্তাফসন

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

— মাইকেল ডুরান্ট

Answer 3

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

Comments

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

— মাত্তেও পাগলিয়াজি

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

— ব্রুস এডিগার

@ অ্যান্ডি এটি নিখুঁত বাজে। সম্পত্তি সেটেটর এবং গেটর উভয়ই তুচ্ছ এবং গুরুত্বপূর্ণ Test যদি তারা কাজ না করে, তবে পুরো ক্লাসটি আলাদা হয়ে যায়। উদাহরণস্বরূপ, একটি মাল্টিথ্রেডেড অ্যাপ্লিকেশনটিতে, যদি সেটটি সমকালীন প্রাপ্তিগুলি প্রতিরোধ না করে, তবে আপনি একটি দূষিত ডেটা ইস্যু পাবেন যা নীচে যেতে কয়েক ঘন্টা সময় নিতে পারে, কারণ ডেটা উত্সটি সঠিক হবে, তবে ফলাফল বা যদি আপনার সেট আপডেটের সময় আপডেট করতে ব্যর্থ হয়, তবে আপনার ডেটা সিঙ্ক করা অসম্ভব হয়ে উঠতে পারে আপনি ধারণা পাবেন। তাহলে setters এবং getters সত্যি সত্যি তুচ্ছ ছিল, আপনি শুধু সম্পত্তি প্রকাশ্য বানাতে পারে

— deworde

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

— অ্যান্ডি

Answer 4

হ্যাঁ, আপনার সবকিছু পরীক্ষা করা উচিত ...

আপনার প্রয়োজনীয় সমস্ত কিছুর জন্য স্বয়ংক্রিয় পরীক্ষা লিখতে সক্ষম হবেন না। আপনার স্থির পৃষ্ঠাগুলির জন্য, জিনিসগুলি সঠিক কিনা তা নিশ্চিত করার জন্য সেলেনিয়াম http://seleniumhq.org/ ব্যবহার করে দেখুন ।

আমার অভিজ্ঞতা থেকে, কিছু সামনে বিষয়গুলি পরীক্ষার কেসগুলি লেখার পক্ষে অসম্ভবের পাশে রয়েছে তবে সে কারণেই আপনি চিহ্নিত করতে পারবেন চিহ্নিত 1 চোখের বলটি ব্যবহার করে।

Comments

আমি একমত নই যদি আপনি এটি কোনও উপহাসের মাধ্যমে বা ডেটাতে যাওয়ার মাধ্যমে ঘটতে না পারেন তবে তা আপনার কোডে কেন। প্রত্যাশিত কার্যকারিতা যাচাইকরণের জন্য সিস্টেমের অন্যান্য ইউনিট পরীক্ষার মাধ্যমে পরীক্ষকগণ এবং সেটারদের নিজস্ব টেস্টের প্রয়োজন হয় না।

— শ্লেইস

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

— অ্যান্ডি 0

Answer 5

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

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

Answer 6

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

Answer 7

অন্যরা যেমন উল্লেখ করেছেন, রুবে অন রেল পরীক্ষা করা এটি অন্যান্য ভাষার চেয়ে বেশি গুরুত্বপূর্ণ। এটি একটি সংকলক না থাকার কারণে।

যেমন ভাষাসমূহ ডেল্ফী , সি ++ VB.NET , ইত্যাদি ... ভাষায় কম্পাইল করা হয়, এবং আপনার কম্পাইলার ধরনের একটি পদ্ধতি কল মধ্যে টাইপস যেমন mistkes অনেকটা কুড়ান হবে। রুবেল অন রেলগুলিতে আপনি কেবল তখনই জানতে পারবেন যে আপনার কোডটিতে টাইপো রয়েছে বা কোনও ভুল আছে যদি সেই নির্দিষ্ট কোডের লাইনটি চালিত হয় বা আপনি কোনও আইডিই ব্যবহার করছেন যা ভিজ্যুয়াল সতর্কতা দেখায়।

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

আমি দেখেছি যে রায়ান বেটস ' পাগল কাস্ট উপর আমি কিভাবে পরীক্ষা আমার কাছে অমূল্য ছিল এবং সত্যিই TBDD সরলতা হাইলাইট যদি সঠিকভাবে সম্পন্ন।

Answer 8

আপনি যদি সত্যিই টিডিডি পদ্ধতি ব্যবহার করে থাকেন তবে আপনি প্রথমে পাসের চেষ্টা করছেন এমন ইউনিট পরীক্ষা না করে কোড লিখবেন না।

Comments

হ্যাঁ ... তবে উদাহরণস্বরূপ একটি স্থির পৃষ্ঠায় আমার কী পরীক্ষা করা উচিত? এর অস্তিত্ব কি? বিষয়বস্তু এবং লিঙ্ক বিদ্যমান? হতে পারে আমি ভুল কিন্তু এটি সময়ের অপচয় বলে মনে হচ্ছে ...

— মাত্তিও পাগলিয়াজি

আমি মনে করি যে টিডিডি পদ্ধতিটি আপনার যুক্তিতে প্রয়োগ করা হয়েছে। আপনার স্থির পৃষ্ঠাটি কি এইচটিএমএল ফাইল? একটি এমভিসি ভিউ যে কখনও পরিবর্তন হয় না? যদি পরের ঘটনাটি আমি অনুমান করি তবে আপনি পরীক্ষা করতে পারেন যে আপনার নিয়ামক সঠিক দর্শনটি ফিরিয়ে দেন। আমি মনে করি আরও গুরুত্বপূর্ণ বিষয়টি মনে রাখবেন যে টিডিডি আপনাকে কেবল "পরীক্ষা" নয় বরং আপনার স্পেসিফিকেশনের বিরুদ্ধে গড়ে তুলতে সহায়তা করবে ...

— wessiyad

আমি ধরে নিলাম আপনি কাঠামোর একটি উপাদান সহ কেবল একটি স্ট্যাটিক পৃষ্ঠা পরিবেশন করছেন। যদি আপনার কোনও পদ্ধতিই সেই পৃষ্ঠাটি স্পর্শ না করে, তবে পরীক্ষার জন্য আসলে কিছুই নেই। আপনারও রেল পরীক্ষা করার দরকার নেই। আমি মনে করি কারও কাছে coveredাকা আছে।

— এরিক রেপেন

Answer 9

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

এটি আমার সমস্যা এখানে। আপনি যখন বলেন যে এটি স্টাফের অনেক সময় নষ্ট করার মতো মনে হয় যা টিডিডার কখনও ভাঙবে না তখন বলে যে আপনি এটির প্রশংসা করবেন যখন আপনি নির্ভর করে না যে বিশাল একটি শৃঙ্খলার উপর নির্ভর করে না এমন একটি জিনিস ফাঁস হয়ে যায়। আপনি যখন উল্লেখ করেন যে আপনি নিজের অ্যাপটি লেখার আগে এই জাতীয় জিনিসগুলির পূর্বাভাস দেওয়া অসম্ভব, যা হ'ল ... কেন আমরা পরীক্ষা করি, তারা আপনাকে বলে যে এটি সত্যই নকশার বিষয়ে এবং টেস্টিং কার্যকর হওয়ার পরেও পরীক্ষার বিষয়ে নয় more

তবে কি অনির্দেশ্য লিঙ্কযুক্ত নির্ভরতাগুলির দৈত্য শৃঙ্খলাগুলি ক্রপ ডিজাইনের পণ্য নয়?

তাহলে এটি কোনটি?

এখানে একটি চিন্তা। ডিজাইন প্যাটার্নগুলি থেকে অবজেক্ট-ভিত্তিক নকশার নিম্নলিখিত দুটি নীতি বিবেচনা করে প্রথমে নির্ভরযোগ্যতার বিশাল জটিল চেইনগুলি না রাখি:

"একটি ইন্টারফেসে প্রোগ্রাম, বাস্তবায়ন নয়"

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

এবং:

"শ্রেণীর উত্তরাধিকারের তুলনায় অবজেক্ট অবজেক্ট রচনা"

কে ডামি? যে লোকটি 30 টি ক্লাসের মতো একটি সংশ্লেষিত ক্যাসকেডিং উত্তরাধিকার প্রকল্পে একটি শ্রেণিতে কিছু করেছিল যার ফলস্রোত কেস ভাঙ্গার ফলে ঘটেছিল, বা দেব যিনি প্রথমে এই স্থাপত্যের সাথে এসেছিলেন? টিডিডি আপনাকে ক্লাস পিসার ঝোঁক টাওয়ারের ভিতরে ইস্যুগুলির তলদেশে পৌঁছাতে সহায়তা করতে পারে যত তাড়াতাড়ি আপনি ছাড়া না পারে তবে পরের বার সেই কোড বিপর্যয়ের শেষ পয়েন্টগুলির মধ্যে একটির সংশোধন করার চেষ্টা করা কি কোনও বেদনাদায়ক হয়ে উঠবে?

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

Answer 10

প্রশ্নের উত্তর দিতে, "এখানে কী ভুল হতে পারে" সম্পর্কে চিন্তা করুন। বিশেষত, আপনি যদি "কোড" পরিবর্তন করেন (মার্কআপ / যাই হোক না কেন), কীভাবে আপনার আত্মবিশ্বাস থাকবে যে আপনি পৃষ্ঠাটি ভাঙ্গেন নি। ভাল, একটি স্থির পৃষ্ঠার জন্য:

• এটি রেন্ডার নাও হতে পারে
• এটি ভুলভাবে রেন্ডার হতে পারে
• জেএস হয়ত লোড করবে না
• চিত্রগুলির জন্য পথগুলি কাজ নাও করতে পারে
• লিঙ্কগুলি নষ্ট হয়ে যেতে পারে

ব্যক্তিগতভাবে, আমি সুপারিশ করব:

• একটি সেলেনিয়াম [1] পরীক্ষা লিখুন যা আপনি পৃষ্ঠায় প্রত্যাশা করেছেন এমন একটি স্ট্রিং পরীক্ষা করে (যদি সম্ভব হয় নীচের দিকে)। এটি বৈধতা দেয় যে এটি রেন্ডার করে।
• কোনও জেএস ত্রুটি নেই তা পরীক্ষা করুন (আমার ধারণা সেলেনিয়াম এটির অনুমতি দেয়)
• এইচটিএমএল যাচাইকারীর মাধ্যমে স্থির পৃষ্ঠাগুলি চালনা করুন এবং যদি সম্ভব হয় তবে একটি লিঙ্ক চেকার।
• আমি জেএসকে যাচাই করতে পছন্দ করি এমন একটি সরঞ্জাম আমি পাইনি তবে আপনি jslint বা jshint এর মাধ্যমে সাফল্য পেতে পারেন।

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

Answer 11

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

পরীক্ষা করুন:

• ব্যবসায়িক যুক্তি
• অ্যাপ্লিকেশন যুক্তি
• কার্যকারিতা
• আচরণ,
• সুতরাং, সবকিছু, সত্যই, ব্যতীত :

পরীক্ষা করবেন না:

• ধ্রুবক
• উপহার

সুতরাং একটি পরীক্ষা থাকার কোন মানে নেই যে বলে:

assert wibble = 3

এবং কিছু কোড যে বলে

wibble = 3

এবং উপস্থাপনা সংক্রান্ত বিষয়গুলি পরীক্ষা করার কোনও অর্থ নেই, যেমন আইকনটি পেরিউইঙ্কল নীল রঙে রয়েছে কিনা, আপনি শিরোনামগুলির জন্য কোন ফন্ট ব্যবহার করেছেন, ইত্যাদি ...

সুতরাং, আপনি জিজ্ঞাসা করেছেন, "আমার কি স্থির পৃষ্ঠাগুলি পরীক্ষা করা উচিত", এবং উত্তরটি হল: তারা আপনার সাইটের কার্যকারিতা, ব্যবসায়িক যুক্তি বা আচরণের অংশ হওয়ায় আপনি তাদের পরীক্ষা করে নিন ins

সুতরাং, আমাদের অ্যাপ্লিকেশনটিতে, আমাদের একটি পরীক্ষা আছে যা পরীক্ষা করে যা সাইটের প্রতিটি অংশ থেকে শর্তাদি এবং শর্তাদি উপলব্ধ রয়েছে - বেনামে ব্যবহারকারীদের জন্য, লগ-ইন করা ব্যবহারকারীদের জন্য, ড্যাশবোর্ড থেকে, অ্যাপ্লিকেশন পর্দার অভ্যন্তর ইত্যাদি এটি ঠিক আছে কিনা তা পরীক্ষা করে that প্রতিটি পৃষ্ঠায় "শর্তাবলী" নামক একটি লিঙ্ক, লিঙ্কটি কাজ করে এবং তারপরে পরীক্ষাটি বলে যে এটি পৃষ্ঠায় উপস্থিত হওয়ার পরে, এটি টিএস এবং সিএসকে "দেখতে" দেখতে "যথেষ্ট সঠিক মনে করে এটি সঠিক পৃষ্ঠা, "একটি ধ্রুবক পরীক্ষা না করা", বা "উপস্থাপনার পরীক্ষা" না করে ... যাতে আপনি পাঠ্যটি সঠিক কিনা তা উদাহরণস্বরূপ নির্দিষ্ট ফন্টের আকার বা পাঠ্য বিন্যাসটি পরীক্ষা না করে পরীক্ষা করতে পারেন ...