আমি স্রেফ "গ্রোয়িং অবজেক্ট-ওরিয়েন্টেড সফ্টওয়্যার" বইয়ের একটি অংশ পড়েছি যা কংক্রিটের ক্লাসকে বিদ্রূপ করার জন্য কেন কিছু কারণ ব্যাখ্যা করে না।
এখানে সংগীত কেন্দ্রের শ্রেণীর জন্য ইউনিট-পরীক্ষার কয়েকটি নমুনা কোড:
public class MusicCentreTest {
@Test public void startsCdPlayerAtTimeRequested() {
final MutableTime scheduledTime = new MutableTime();
CdPlayer player = new CdPlayer() {
@Override
public void scheduleToStartAt(Time startTime) {
scheduledTime.set(startTime);
}
}
MusicCentre centre = new MusicCentre(player);
centre.startMediaAt(LATER);
assertEquals(LATER, scheduledTime.get());
}
}
এবং তার প্রথম ব্যাখ্যা:
এই পদ্ধতির সাথে সমস্যা হ'ল এটি অন্তর্ভুক্ত বস্তুর মধ্যে সম্পর্ককে ছেড়ে দেয়। আমি আশা করি আমরা এতক্ষণে পরিষ্কার করে দিয়েছি যে মক অবজেক্টসের সাথে টেস্ট-চালিত বিকাশের উদ্দেশ্য হ'ল বস্তুর মধ্যে সম্পর্ক আবিষ্কার করা। যদি আমি সাবক্লাস করি তবে এ জাতীয় সম্পর্কটিকে দৃশ্যমান করার জন্য ডোমেন কোডে কিছুই নেই, কেবল কোনও জিনিসে কেবল পদ্ধতি। এটি এই সম্পর্কটিকে সমর্থন করে যে পরিষেবাটি অন্য কোথাও প্রাসঙ্গিক হতে পারে তা দেখার পক্ষে এটি আরও কঠিন করে তোলে এবং পরের বার যখন ক্লাসের সাথে কাজ করবেন তখন আমাকে আবার বিশ্লেষণ করতে হবে।
তিনি যখন বলেছিলেন তখন তার ঠিক কী অর্থ আমি বুঝতে পারি না:
এটি এই সম্পর্কটিকে সমর্থন করে যে পরিষেবাটি অন্য কোথাও প্রাসঙ্গিক হতে পারে তা দেখার পক্ষে এটি আরও কঠিন করে তোলে এবং পরের বার যখন ক্লাসের সাথে কাজ করবেন তখন আমাকে আবার বিশ্লেষণ করতে হবে।
আমি বুঝতে পারি যে পরিষেবাটি কল করা MusicCentreপদ্ধতির সাথে সম্পর্কিত startMediaAt।
তিনি "অন্য কোথাও" বলতে কী বোঝায়?
সম্পূর্ণ উদ্ধৃতিটি এখানে: http://www.mockobjects.com/2007/04/test-smell-mocking-concrete-classes.html