টিডিডি কেন কাজ করে? [বন্ধ]

Question

টেস্ট-চালিত বিকাশ (টিডিডি) আজকাল বড়। আমি প্রায়শই এটি প্রোগ্রামার এসই এবং অন্যান্য স্থানগুলিতে বিস্তৃত সমস্যার সমাধান হিসাবে প্রস্তাবিত দেখতে পাই। আমি ভাবছি কেন এটি কাজ করে।

ইঞ্জিনিয়ারিং দৃষ্টিকোণ থেকে, এটি দুটি কারণে আমাকে ধাঁধা দেয়:

1. "পাস পর্যন্ত লেখার পরীক্ষা + রিফ্যাক্টর" পদ্ধতির অবিশ্বাস্যভাবে অ্যান্টি-ইঞ্জিনিয়ারিং দেখায়। সিভিল ইঞ্জিনিয়াররা যদি সেতুটি নির্মাণের জন্য সেই পদ্ধতিটি ব্যবহার করেন, বা তাদের গাড়িগুলির জন্য গাড়ি ডিজাইনার ব্যবহার করেন, উদাহরণস্বরূপ, তারা খুব বেশি ব্যয়ে তাদের সেতু বা গাড়ি পুনর্নির্মাণ করবে এবং ফলস্বরূপ কোনও সুচিন্তিত আর্কিটেকচার ছাড়াই প্যাচ-আপ জঞ্জাল হবে would । "রিফ্যাক্টর অব পাস অব" গাইডলাইনটি প্রায়শই আর্কিটেকচারাল ডিজাইনের কথা ভুলে যাওয়ার এবং পরীক্ষার সাথে মেনে চলার জন্য যা যা করা প্রয়োজন তা করার ম্যান্ডেট হিসাবে নেওয়া হয় ; অন্য কথায়, পরীক্ষা, ব্যবহারকারীর পরিবর্তে, প্রয়োজনীয়তা নির্ধারণ করে। এই পরিস্থিতিতে আমরা কীভাবে ফলাফলগুলিতে ভাল "দক্ষতার" গ্যারান্টি দিতে পারি, অর্থাত্ একটি চূড়ান্ত ফলাফল যা সঠিক নয় কেবল এক্সটেনসিবল, মজবুত, সহজেই ব্যবহারযোগ্য, নির্ভরযোগ্য, নিরাপদ, সুরক্ষিত ইত্যাদি? আর্কিটেকচার সাধারণত এটি করে।
2. পরীক্ষা কোনও গ্যারান্টি দিতে পারে না যে কোনও সিস্টেম কাজ করে; এটি কেবল দেখায় যে এটি না। অন্য কথায়, পরীক্ষা আপনাকে দেখাতে পারে যে কোনও সিস্টেমে কোনও পরীক্ষা ব্যর্থ হলে এটির ত্রুটি রয়েছে, তবে যে সমস্ত সিস্টেম পরীক্ষায় উত্তীর্ণ হয়, সে ব্যবস্থার চেয়ে এটি ব্যর্থ হওয়া সিস্টেমের চেয়ে নিরাপদ নয়। পরীক্ষার কভারেজ, পরীক্ষার মান এবং অন্যান্য কারণগুলি এখানে গুরুত্বপূর্ণ। একটি "সমস্ত সবুজ" ফলাফল বহু লোকের জন্য যে মিথ্যা নিরাপদ অনুভূতি জন্মায় তা নাগরিক এবং মহাকাশ শিল্পগুলিতে অত্যন্ত বিপজ্জনক হিসাবে রিপোর্ট করা হয়েছে, কারণ এটি "সিস্টেম ভাল আছে" হিসাবে ব্যাখ্যা করা যেতে পারে, যখন এর সত্যিকার অর্থে "সিস্টেমটি তত ভাল আমাদের পরীক্ষার কৌশল হিসাবে "। প্রায়শই, পরীক্ষার কৌশলটি পরীক্ষা করা হয় না। বা, কে পরীক্ষা দেয়?

সংক্ষেপে, আমি টিডিডিতে "চালিত" বিট সম্পর্কে "পরীক্ষা" বিটের চেয়ে বেশি উদ্বিগ্ন। পরীক্ষা নিখুঁত ঠিক আছে; আমি যা পাই না তা হ'ল ডিজাইনটি চালিয়ে।

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

Comments

ব্রিজ, গাড়ি এবং অন্যান্য শারীরিক নকশাগুলি সফ্টওয়্যারটির মতো দূষিত নয় le এটি একটি গুরুত্বপূর্ণ পার্থক্য এবং এর অর্থ সফ্টওয়্যার এবং প্রকৃত প্রকৌশলগুলির মধ্যে তুলনা সর্বদা প্রাসঙ্গিক নয়। ব্রিজগুলির জন্য যা কাজ করে তা সফ্টওয়্যারটির জন্য কাজ না করে এবং বিপরীতে।

— লার্স ভাইর্জনিয়াস

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

— 6502

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

— Mchl

@ সিজারগন, আপনিও এই প্রশ্নে আকর্ষণীয় হতে পারেন যে আমি কিছুক্ষণ আগে এসও এর কাছে জিজ্ঞাসা করেছি ... বেশ টিডিডি নয়, তবে সম্পর্কিত ... কিছু খুব আলোকিত উত্তর সেখানে।

— এভিডি

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

Answer 1

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

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

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

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

এগুলি হ'ল টিডিডি দিয়ে আপনি স্থাপন করতে পারেন।

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

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

Comments

উত্পাদন যেখানে টেস্টিং ঘটে তা নিয়ে কথা বলার জন্য +1। দুর্দান্ত পয়েন্ট।

— অ্যাডাম শিখুন

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

— সিজারগন

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

— ইনকা

+1: সফ্টওয়্যার খাঁটি ডিজাইন। প্রশ্নে ব্রিজ উপমা সম্পূর্ণ ভুল। টিডিডি সম্পূর্ণরূপে ইউনিট পরীক্ষার বাইরে প্রয়োগ করে। টেস্ট-চালিত ডিজাইন নকশার সমস্ত স্তরে প্রযোজ্য।

— এস .লট

@CesarGon: না, TDD- এ ড্রাইভিং ডেভেলপমেন্ট পরীক্ষামূলক দ্বারা। এটি ডিজাইনের গাড়ি চালানোর চেয়ে আলাদা। ডিজাইনটি নির্দেশ করে যে আপনি কীভাবে সিস্টেমটি ব্যবহার করবেন এবং এই আচরণটির প্রতিরূপ তৈরি করতে আপনাকে কোন পরীক্ষাগুলি প্রয়োগ করতে হবে। যদিও এই পরীক্ষাগুলি কার্যকর করা আপনাকে প্রায়শই নকশাকে পরিমার্জন করতে সহায়তা করে ।

— ডিফোর্ড

Answer 2

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

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

পিটার নরভিগ কোডারস এট ওয়ার্ক বইতে টিডিডি সম্পর্কে তাঁর দৃষ্টিভঙ্গি ব্যাখ্যা করেছেন।

Seibel: ডিজাইন ড্রাইভ করতে পরীক্ষা ব্যবহার করার ধারণা সম্পর্কে কী?

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

Comments

এখন, আপনি যদি এই বিষয়গুলি টিডিডি ভাবেন এবং পরামর্শদাতাদের বলেন তবে আপনার যে উত্তরটি পাওয়া যাবে তা well, you haven't done TDD right!

— হ'ল

এবং তারা ঠিক হবে। আমরা খুব উচ্চ ভলিউম সিস্টেমে বিডিডি / টিডিডি করছি, এবং এটি ভালভাবে কাজ করছে। পরীক্ষাগুলি আপনাকে বলার জন্য রয়েছে যে আপনি প্রত্যাশিত আচরণটি ভঙ্গ করেছেন। যদি আপনি পরীক্ষাগুলি পরে "ব্রেকিং" করে চলেছেন এবং বাস্তবে এটি ভুল করছেন are সিস্টেমের নতুন আচরণকে দৃ solid় করার জন্য পরীক্ষাগুলি প্রথমে পরিবর্তন করা উচিত, তারপরে আপনি এটি পরিবর্তন করুন। এবং হ্যাঁ, আপনি যদি এটি সঠিকভাবে করছেন, আপনি "এই জিনিসটির কী করা দরকার" দিয়ে শুরু করে আপনার পরীক্ষাগুলি লিখুন এবং পরীক্ষা লেখার প্রক্রিয়া আপনাকে "আইটি এর কাজটি করার জন্য কী প্রয়োজন" ভেবে সহায়তা করে। ওহ, এবং কোনও পরামর্শক কখনও ব্যবহার করা হয়নি ...

— অ্যান্ডি

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

— নিউটোপিয়ান

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

— ডঙ্ক

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

— জর্জিও

Answer 3

টেস্ট ড্রাইভড ডিজাইন নিম্নলিখিত কারণে আমার জন্য কাজ করে:

এটি স্পেসিফিকেশন একটি চলমান ফর্ম।

এর অর্থ হল আপনি পরীক্ষার কেসগুলি থেকে দেখতে পারবেন:

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

আপনি প্রথমে বাইরে থেকে ভিউটি লিখবেন।

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

এটি সাধারণত ক্লিনার কোডেও ফলাফল দেয় যার জন্য কম ব্যাখ্যামূলক ডকুমেন্টেশন প্রয়োজন।

আপনি দ্রুত সম্পন্ন করা

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

এর অর্থ হ'ল আপনি যখন বলতে পারবেন যে কখন কাজটি প্রয়োজনীয় হয় বা না (এটি কোনও পরীক্ষায় উত্তীর্ণ হতে সহায়তা করে) আপনার কম কাজ করার দরকার পড়ে।

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

সাম্প্রতিক গবেষণা

"কেস স্টাডির ফলাফলগুলি ইঙ্গিত দেয় যে টিডিডি অনুশীলন ব্যবহার না করে এমন চারটি পণ্যের প্রাক-প্রকাশের ত্রুটির ঘনত্ব 40% থেকে 90% এর মধ্যে হ্রাস পেয়েছে। বিষয়সত্ত্বে, দলগুলি 15 থেকে 35% বৃদ্ধি পেয়েছিল টিডিডি গ্রহণের পরে প্রাথমিক বিকাশের সময়। " ~ ফলাফল এবং 4 ইন্ডাস্ট্রিয়াল দলসমূহ এর অভিজ্ঞতা

Comments

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

— এডওয়ার্ড স্ট্রেঞ্জ

এটি গ্রহণযোগ্য উত্তর হওয়া উচিত।

— নিইং

Answer 4

সফ্টওয়্যার তৈরির প্রক্রিয়াটি কোড লেখার প্রক্রিয়া নয়। প্রথমে কোনও 'ব্রড স্কোপ' পরিকল্পনা ছাড়া কোনও সফ্টওয়্যার প্রকল্প শুরু করা উচিত নয়। ঠিক যেমন নদীর দু'কোটি সেতুর একটি প্রকল্পের প্রথমে এমন পরিকল্পনা প্রয়োজন needs

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

স্ট্রাকচারাল ইঞ্জিনিয়ারিং এ এটি কিছুটা দেখতে লাগে:

'আমাদের এই দুটি টুকরো ধাতব একসাথে সংযুক্ত রয়েছে, এবং সংযোগটির এক্সের ক্রমতে শিয়ার বাহিনী বজায় রাখা দরকার to আসুন পরীক্ষা করা যাক কোন সংযোগ পদ্ধতিটি এটি করার জন্য সেরা one '

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

ভি-মডেল দেখুন: http://en.wikedia.org/wiki/V- মডেল_৯২০ সফটওয়্যার_ডিভালপমেন্ট ৯৯৯

আসুন দেখুন কীভাবে এটি একটি ব্রিজের জন্য কাজ করবে:

1. একটি স্থানীয় সরকার একটি সেতু নির্মাণকারী সংস্থাকে বলেছে: "এই দুটি পয়েন্টের সংযোগ স্থাপনের জন্য আমাদের একটি সেতুর প্রয়োজন। সেতুটি প্রতি ঘন্টা ২ ঘন্টা ট্র্যাফিকের অনুমতি দিতে সক্ষম হতে হবে এবং 21 শে ডিসেম্বর ২০১২ 'এর জন্য প্রস্তুত থাকতে হবে - এটি একটি সংজ্ঞা গ্রহণযোগ্যতা পরীক্ষা The সংস্থাটি যদি তারা এই পরীক্ষায় পাস করতে না পারে তবে পুরো পরিমাণ (বা কোনও) অর্থ পাবে না।

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

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

Comments

যদি আমি আপনাকে সঠিকভাবে বুঝতে পারি তবে আপনি বলছেন যে টিডিডি ঠিক আছে যতক্ষণ না (ক) এটি কেবল ইউনিট পরীক্ষার জন্য ব্যবহৃত হয় এবং (খ) এটি অন্যান্য পরীক্ষার পদ্ধতির সাথেও থাকে। যদি এটি হয় তবে এটি ওপিতে 2 নম্বর পয়েন্টটিকে সম্বোধন করতে পারে। আপনি পয়েন্ট নম্বর 1 ঠিকানা হবে?

— সিজারগন

@ সিজারগন: টিডিডি ইন্টিগ্রেশন পরীক্ষার জন্যও দুর্দান্ত কাজ করে।

— সেভেনসিয়াট

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

— Mchl

@ কার্পি: এবং গ্রহণযোগ্যতা পরীক্ষার জন্যও! আপনার কাজটি ক্লায়েন্টের দ্বারা গৃহীত হওয়ার জন্য আপনার কী প্রয়োজন তা আগেই জেনে রাখা উচিত।

— Mchl

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

— Mchl

Answer 5

আমার মনে টিডিডি কাজ করে কারণ

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

আপনি উত্থাপন পয়েন্টগুলি বিশেষত

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

Comments

আপনার আরও যোগ করা উচিত যে ত্রুটিগুলি যেমন আবিষ্কার করা হয় আপনি তা নিশ্চিত করতে পারেন যে আপনি অন্য পরীক্ষা যুক্ত করার সাথে সাথে সেগুলি পুনরাবৃত্তি হবে না।

— অ্যান্ডি

Answer 6

টি এল; ডিআর

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

কোড ডিজাইন

পিপিপি "আঙ্কেল বব" এর 7 অধ্যায়ে এই সমস্যাটি সম্পর্কে সরাসরি আলোচনা হয়েছে talks অধ্যায়টির খুব প্রথম দিকে, তিনি জ্যাক রিভসের একটি দুর্দান্ত নিবন্ধটি উল্লেখ করেছেন যাতে তিনি প্রস্তাব করেন যে কোডটি ডিজাইন করা হয়েছে (লিঙ্কটি এই বিষয়টিতে তার তিনটি নিবন্ধ সংগ্রহ করে একটি পৃষ্ঠায় যায়)।

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

স্পেসিফিকেশন হিসাবে টিডিডি

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

কার্যকারিতা টেস্ট লিখুন

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

public class PersonTest:Test
{
   [Test]
   TestNameProperty()
   {
      var person=new Person();
      person.Name="John Doe";
      Assert.AreEqual("John Doe", person.Name);
   }
}

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

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

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

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

Comments

বাগগুলি ধরার জন্য লাল পরীক্ষার মান হ'ল ইউনিট পরীক্ষার একটি বৈশিষ্ট্য, বিশেষভাবে টিডিডি নয়।

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

আপনি ঠিক এই পয়েন্টে। তবে আমার যে নির্দিষ্ট বাগটি পোস্ট-হক ইউনিট পরীক্ষার সাথে আচ্ছাদিত তা কম হওয়ার সম্ভাবনা কম।

— মাইকেল ব্রাউন

আপনি কি কিছু দাবি, তথ্য বা কঠিন বিশ্লেষণের সাহায্যে এই দাবিটিকে সমর্থন করতে পারেন?

— সিজারগন

@ সিজারগন এই সমীক্ষায় , যখন একটি ছোট প্রকল্পে প্রোগ্রামাররা কাজ করছেন, পরামর্শ দিয়েছিলেন যে টিডিডি ব্যবহারকারী বিকাশকারীরা সত্য-পরবর্তী পরীক্ষার তুলনায় (92% -98% বনাম 80% -90%) এর চেয়ে ভাল পরীক্ষার কভারেজ সহ কোড তৈরি করে এবং ফলস্বরূপ আরও ধরা উন্নয়নের সময় ত্রুটি (টিডিডি ব্যবহার করে উত্পাদিত কোডটিতে 18% কম ত্রুটি পাওয়া যায়)

— জুলে

Answer 7

আপনি পরীক্ষা চালিত বিকাশ, বা এমনকি টেস্ট চালিত নকশার নকশা (তারা আলাদা), এমন কাউকে পাবেন না যা পরীক্ষাগুলি প্রয়োগগুলি প্রমাণ করে। সুতরাং কেবল যে একটি খড় মানুষ কল এবং সম্পন্ন করা যাক।

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

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

সুতরাং, টিডিডি এবং টিডিডি-র মধ্যে পার্থক্য নয় যে পরীক্ষা করা হচ্ছে। পরীক্ষাগুলি লেখার সময় পার্থক্য। টিডিডি পরীক্ষায় সফ্টওয়্যার আগে লেখা হয়। নন-টিডিডি পরীক্ষাগুলি সফ্টওয়্যারটির পরে বা কনসার্টে লেখা হয়।

দ্বিতীয়টির বিষয়ে আমি যে বিষয়টি দেখেছি তা হ'ল পরীক্ষার পরে সফ্টওয়্যারটি কাঙ্ক্ষিত ফলাফল বা নির্দিষ্টকরণের চেয়ে বেশি লেখা হচ্ছে target এমনকি টেস্টিং দলটি উন্নয়ন দল থেকে পৃথক হওয়া সত্ত্বেও, পরীক্ষার দলটি সফ্টওয়্যারটি দেখতে, এটি খেলতে এবং এটি লক্ষ্য করে এমন পরীক্ষাগুলি লেখার ঝোঁক।

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

টিডিডির লক্ষ্য হ'ল এই "বিজ্ঞপ্তি যুক্তি" ভঙ্গ করা এবং সফ্টওয়্যারটি যা নিজে সফ্টওয়্যার নয় তা পরীক্ষার জন্য ভিত্তি সরবরাহ করা। "গ্রাহক" যে আচরণ চান সেটি লক্ষ্য করে পরীক্ষাগুলি লেখা হয়। সফ্টওয়্যারটি তখন সেই পরীক্ষাগুলি পাস করার জন্য লেখা হয়।

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

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

Comments

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

— সিজারগন

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

— এডওয়ার্ড স্ট্রেঞ্জ

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

— সিজারগন

না। আমাদের বিল্ডগুলি স্বয়ংক্রিয় হয়। তারা পরিবর্তন দ্বারা ট্রিগার করা হয়। যেমনটি আমি বলেছিলাম, টিডিডি সমাধানের অংশ মাত্র।

— এডওয়ার্ড স্ট্রেঞ্জ

Answer 8

প্রথমে ডিজাইন করুন

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

তবে তাড়াতাড়ি পরীক্ষা করুন

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

পরীক্ষা এবং নকশা ... এক এবং একই

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

তাহলে শো চালান কে?

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

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

টেস্টগুলি কঠিন হিসাবে দীর্ঘ

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

হ্যাঁ, তবে আমি যদি আমার সেতু দিয়ে এটি করি ...

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

যদি এটি খুব ভাল আসে তবে এটি কীভাবে সর্বদা কার্যকর হয় না?

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

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

টোর এই দলগুলি টিডিডি যাওয়ার উপায় নাও হতে পারে।

Answer 9

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

আপনি যখন পরীক্ষাগুলি দ্বারা সমর্থিত আরও ভাল ফ্যাক্টর কোড রাখেন তখন প্রকল্পের নতুন বিকাশকারীটির পক্ষে দ্রুত গতিতে আসা আরও সহজ।

Comments

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

— মার্ফ

@ মার্ফ হ্যা টিডিডি আপনাকে সৎ রাখতে সহায়তা করে :)

— এলব

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

— মার্ফ

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

— আদম লিয়ার

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

— মারফ

Answer 10

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

1) আমার প্রথম গ্রহণটি হ'ল, এটি (প্রাথমিকভাবে) কোডের (যেমন) টিডিডি "উন্নত মানের" যুক্ত করার কারণে নয়, এটি টিডিডি সবচেয়ে খারাপ অংশ এবং অভ্যাসগুলি ছাঁটাইতে সহায়তা করে এবং তাই পরোক্ষভাবে গুণমান বাড়ায়।

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

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

Comments

+1 আমি মনে করি আপনি এটি পেরেক দিয়েছিলেন, ম্যাগলব। আমি বিশেষত আপনার ব্যাখ্যাটি পছন্দ করি যে "টিডিডি সবচেয়ে খারাপ অংশ এবং অভ্যাসগুলি ছড়িয়ে দিতে সহায়তা করে, [...] পরোক্ষভাবে গুণমান বাড়িয়ে তোলে"। এবং দীর্ঘ দাড়ি উপমাটিও খুব ভাল।

— সিজারগন

আপনি কোনও খারাপ কোডের জন্য পরীক্ষা লেখেন না, তবে আপনি একটি পরীক্ষা লিখেন এবং তারপরে পরীক্ষার পাস করার জন্য কোডটি লিখুন।

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

— ফিলিপ দুপানোভিć

Answer 11

"পাস অবধি পরীক্ষার জন্য + লেখার প্রক্রিয়া" পদ্ধতির অবিশ্বাস্যভাবে অ্যান্টি-ইঞ্জিনিয়ারিং দেখাচ্ছে looks

আপনার কাছে রিফ্যাক্টরিং এবং টিডিডি উভয় সম্পর্কে একটি ভুল ধারণা রয়েছে বলে মনে হচ্ছে।

কোড রিফ্যাক্টরিং হ'ল সফ্টওয়্যারটির অযৌক্তিক বৈশিষ্ট্যগুলির কিছু উন্নত করার জন্য কোনও কম্পিউটার প্রোগ্রামের উত্স কোডের বাহ্যিক কার্যক্ষম আচরণটি পরিবর্তন না করেই পরিবর্তন প্রক্রিয়া।

এটি পাস না হওয়া পর্যন্ত আপনি কোডটি রিফ্যাক্টর করতে পারবেন না ।

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

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

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

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

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

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

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

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

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

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

Comments

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

— সিজারগন

@ সিজারগন: পোস্ট আপডেট হয়েছে।

— back2dos

Answer 12

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

সফ্টওয়্যারটির ভিত্তি তৈরি করে এমন লাইব্রেরিগুলি পরীক্ষা করা ছাড়াও আপনার ব্যবহারকারীরা সফ্টওয়্যার / ওয়েবসাইট / যা কিছু হোক না কেন তার সাথে ইন্টারঅ্যাকশনগুলি কভার করে সেগুলি পরীক্ষা করুন। এগুলি সরাসরি ব্যবহারকারীদের কাছ থেকে আসে এবং শসা জাতীয় লাইব্রেরি (http://cukes.info) এমনকি আপনার ব্যবহারকারীদের নিজেরাই প্রাকৃতিক ভাষায় পরীক্ষা লিখতে দেয়।

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

এবং সেতু এবং গাড়িগুলির বিপরীতে, একক টুকরো সফ্টওয়্যার তার জীবদ্দশায় ব্যাপক পরিবর্তন আনতে পারে এবং প্রথমে পরীক্ষাগুলি না লিখে জটিল রিফ্যাক্টরিং করা কেবল সমস্যার জন্য জিজ্ঞাসা করা।

Comments

আপনি টিডিডির জন্য যে সুবিধা দাবি করেন তা সম্পর্কে আমি শুনছি। তবে যতদূর আমি বুঝতে পেরেছি আপনি আর্কিটেকচার এবং পরীক্ষার মানের বিষয়ে যে প্রশ্নগুলি স্পষ্টভাবে আমার প্রশ্নে জিজ্ঞাসা করছেন সেগুলি আপনি সম্বোধন করেন না।

— সিজারগন

@ সিজারগন: আমি মনে করি যে আপনার নির্দিষ্ট প্রশ্নগুলি কেবল টিডিডি নয়, যে কোনও ধরণের পরীক্ষার ক্ষেত্রে প্রযোজ্য। সুতরাং আমি কেবল টিডিডি'র 'কাজ' এর নির্দিষ্ট বৈশিষ্ট্যগুলিতে মনোনিবেশ করেছি।

— সেভেনসিট

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

Answer 13

আমি মনে করি আপনি ভুল কোণ থেকে প্রথম পয়েন্টে পৌঁছেছেন।

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

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

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

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

Comments

আমার প্রথম বিষয়টির একটি ভাল ব্যাখ্যা এবং হ্যাঙ্ক মুডির রেফারেন্সের জন্য +1। মহিমান্বিত।

— সিজারগন

ধন্যবাদ আমি এটা প্রশংসা করি. আমি প্রযুক্তিগত পন্থা / প্রক্রিয়া না করে টিডিডিটিকে একটি মনস্তাত্ত্বিক ঘটনা হিসাবে বেশি দেখি। তবে বিষয়টি সম্পর্কে আমার বিশ্ব-দৃষ্টিভঙ্গি।

— ফিলিপ দুপানভিভিć

আপনি ঠিক কতটি ল্যাভেটরি এবং কোথায় স্থাপন করা উচিত তা জানতে পারবেন? উত্তর হ্যাঁ - যান কোনও স্থপতি জিজ্ঞাসা করুন এবং তারা আপনাকে বলবে যে এই তথ্যটি আপ-ফ্রন্ট এবং কখনও কখনও স্পষ্ট পরিসংখ্যানের ডেটা সহ এটির ব্যাক আপ করার জন্য তৈরি করা হয়।

— gbjbaanb

Answer 14

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

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

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

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

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

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

Comments

আমি আপনার অন্তর্ভুক্তির সাথে একমত নই যে শারীরিক (অর্থাৎ নন-সফ্টওয়্যার) সিস্টেমে ব্যর্থতা পুনরুত্পাদন করা সহজ। অত্যন্ত জটিল, কঠোর পরিশ্রমের দিকে লক্ষ্য করুন যা বিমানের ট্র্যাফিক দুর্ঘটনায় যান্ত্রিক ব্যর্থতার মূল কারণগুলি নির্ধারণ করার জন্য প্রয়োজনীয় ।

— সিজারগন

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

— এরনেলি

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

— gbjbaanb

Answer 15

আপনি যদি স্বীকার করেন যে যত তাড়াতাড়ি বাগগুলি পাওয়া যায়, সেগুলি ঠিক করার ব্যয় কম হয়, তবে এটি একা টিডিডিকে সার্থক করে তোলে।

Comments

আপনার কাছে কি কোনও প্রমাণ আছে যে কোনও টিডিডি সেটিংয়ে তড়িঘড়ি বাগগুলি পাওয়া যায়? এছাড়াও, টিডিডি এর পার্শ্ব প্রতিক্রিয়াগুলি, যেমন আর্কিটেকচারের উপর প্রভাব সম্পর্কে কী?

— সিজারগন

Answer 16

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

একটি দুর্দান্ত পার্শ্ব সুবিধা হিসাবে, আপনার পরীক্ষাগুলির একটি বড় স্যুট রয়েছে যা আপনি নিশ্চিত করতে চালাতে পারেন যে কোনও রিফ্যাক্টরিং আপনার সফ্টওয়্যারটির আচরণ (ইনপুট এবং আউটপুট) পরিবর্তন করে না।

Comments

-1। প্রচুর লোক এটি বলে চলেছে, তবে এখনও আমার কাছে সেই জাদুটি দেখা যায় নি যা এটি ঘটায়।

— বার্ট ভ্যান ইনজেন শেনৌ

@ বার্ট ভ্যান ইনজেন শেনৌ, আপনি কি টিডিডি করেছেন? আমি এটি প্রায় 4 বছর ধরে করছি এবং আমি অবশ্যই "যাদু" ঘটতে দেখেছি।

— মারসি

Answer 17

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

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

Answer 18

সফ্টওয়্যার জৈব, যখন স্ট্রাকচারাল ইঞ্জিনিয়ারিং কংক্রিট হয়।

আপনি যখন নিজের সেতুটি তৈরি করেন, তখন এটি একটি সেতুতে থাকবে এবং এটি অল্প সময়ের মধ্যেই অন্য কোনও কিছুতে রূপান্তরিত হওয়ার সম্ভাবনা কম। মাস এবং বছর ধরে উন্নতি করা হবে, তবে সফ্টওয়্যারটির মতো ঘন্টা এবং দিন নয়।

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

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

সংক্ষেপে বলতে গেলে, আমি বিশ্বাস করি যে এর পেছনে চিন্তাভাবনাটি হ'ল এটি যদি আপনার নকশাটি পরীক্ষামূলক হয় তবে এটি আলগাভাবে মিলিত হয় এবং এটির উদ্বেগের একটি ভাল বিভাজন রয়েছে।

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

Answer 19

টিডিডি কেন কাজ করে?

এটা না।

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

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