الأكل و النوم و التنفس اختبار وحدة/TDD/BDD [مغلقة]

Question

أنا لا أكتب وحدة الاختبارات أثناء كتابة واجهات برمجة التطبيقات و الوظائف الأساسية.ولكن أريد أن تكون باردة بوي الذي يأكل وينام ويتنفس TDD و BDD.ما هي أفضل طريقة للحصول بدأت مع TDD/BDD الطريق الصحيح ؟ أي الكتب والموارد أطر أفضل الممارسات ؟

بلدي بيئة جافا الخلفية مع الكؤوس الواجهة متكامل مع العديد من الخدمات الخارجية الويب وقواعد البيانات.

Answer 1

مكان جيد للبدء هو قراءة بلوق.ثم شراء الكتب من الناس الذين المدونات.بعض سأكون في غاية يوصي:

"العم بوب" مارتن الرجال في وجوه معلمه:http://blog.objectmentor.com/

P. S.الحصول على البوب الكتاب رمز نظيفة:

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

صديقي تيم Ottinger (السابق الكائن معلمه يا صاح) http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/

على Jetbrains الرجال:http://www.jbrains.ca/permalink/285

شعرت بالحاجة إلى التوسع في هذا ، كما يبدو الجميع في أن فقط أريد أن أقدم لكم رأيهم TDD و لا تساعدك على سعيكم لتصبح جدي-النينجا.مايكل الأردن من TDD كينت بيك.انه حقا لم يكتب الكتاب على ذلك:

http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

كما المدونات في:

http://www.threeriversinstitute.org/blog/?p=29

أخرى "الشهيرة" أنصار TDD تشمل:

• تيم براي
• مارتن فاولر
• Ward Cunningham

جميع الشعب العظيم أن يتبع.يجب عليك أن تنظر أيضا حضور بعض المؤتمرات مثل رشيقة 2010 ، أو البرامج الحرفية (هذا العام كانوا محتجزين في نفس الوقت في شيكاغو)

Answer 2

وأنا لا أحب ذلك عندما يقول الناس "الممارسة X أبدا سيئة، وإذا كان لا يعمل، وكنت لا تفعل ذلك الحق." عذرا، فقد يشعر نفسه بأنه أي عقيدة دينية الإفراط في حماسية أخرى. أنا لا شرائه.

وأنا أتفق مع هؤلاء الناس الذين يقولون أن أفضل حل الوقت والمال يمكن أن تحمل ينبغي أن يكون الهدف.

وأي شخص يعترض على TDD لا ينبغي أن يكون تلقائيا المتهمين تجاهل الجودة. ( "لذلك عندما هل وقف الضرب زوجتك؟") والحقيقة هي أن البرنامج لديه الخلل في ذلك، وتكلفة القضاء على كل منهم يجب أن يكون وزنه ضد صالح.

ويصدق الشيء نفسه في التصنيع. التفاوتات في الأبعاد والتشطيبات على الأسطح ليست كل نفس، لأن في بعض الأحيان لا يبرر التسامح وثيق والانتهاء من المرآة.

نعم، أنا أكتب وحدة الاختبارات، وإن لم يكن في كثير من الأحيان قبل أن أكتب الطبقة. رأيت تأثير التجارب على التصميم. I قياس ومشاهدة تغطية رمز. إذا وجدت أن التغطية بلدي أمر غير مقبول، وأنا أكتب لمزيد من الفحوص. وأنا أفهم الاستفادة من وجود شبكة أمان وحدة الاختبارات لإعادة الهيكلية. أتابع تلك الممارسات حتى عندما أعمل وحدها، لأنني قد شهدت فوائد مباشرة. أحصل عليه.

ولكن أود أن ننظر بارتياب في أي زميله الذي بدأ التنصت لي عن "الأكل، والنوم، والتنفس اختبار وحدة وTDD".

<اقتباس فقرة>   

ومدير أعمالي يقول أن الطريقة الوحيدة التي سوف تحصل لي تعزيزها ما اذا كان يمكنني الحصول على فريق لTDD / BDD.

ومن أي وقت مضى أعتقد أنه ربما هذا يجعلك تبدو وكأنها تمتص المتابعة؟ هل وجدت أن المزعجة بك تسبب في نفور بقية فريقك؟

وهذه الاستجابة قد يفقد لي بضع نقاط سمعة، ولكن كان يجب أن يقال.

وأعتقد أن النهج الأفضل أن يكون لممارسة ذلك بنفسك وتدع الآخرين يرون فائدة. مثالا يحتذى به. انها سوف تكون أكثر إقناعا من تشغيل فمك.

والجيز، الكؤوس المقدسة لدى الجيل اختبار مدمج. إذا كنت تعمل على الفريق الذي يستخدم الكؤوس المقدسة، هناك حاجة إلى مزيد وكم بيع؟

Answer 3

وأفضل الممارسات IMHO: هل ما هو عملي وليس فقط لأنه هو عملية. لا ننسى ما الهدف من كتابة الطلبات هو، وفي عالم الأعمال، فإنه ليس من كتابة الاختبارات. لا تفهموني خطأ، لديهم مكانهم، ولكن هذا لا ينبغي أن يكون الهدف.

Answer 4

والبحث عن شخص ما قام به TDD / BDD وبرنامج الزوج معها.

Answer 5

والمقاييس هي، IMHO، وأفضل طريقة للحصول من هنا الى هناك. تتبع جيدا كيف يتم تغطية التعليمات البرمجية الخاصة بك، والحفاظ على دلتا كود تعقيد لكل ارتكابها، واستخدام اختبار المتسابقين أن مشاهدة التعليمات البرمجية لإجراء تغييرات وتعمل باستمرار على إعادة تشغيل اختبارات المقابلة. لا تدع أطوال اختبار الحصول على أعلى بضعة أسطر، بحيث كل ما تبذلونه من أدوات تعمل بشكل جيد. وانصح مرة واحدة في الشهر، تأخذ يوم عطلة لتشغيل التعليمات البرمجية الخاصة بك من خلال اختبار الطفرة. ينبغي تخصيص ذلك اليوم لكتابة الاختبارات فقط. وكل هذه الاشياء تجلب لك الألم إذا كنت لا تفعل بالفعل TDD جيد. تعلم من الألم، وفي أي وقت من الأوقات على الإطلاق، عليك أن تفعل ذلك الحق.

وأبدا يغيب عن بالنا ما هي اختبارات: لوصف السلوك المطلوب. وهي مواصفات القابل للتنفيذ. (وهذا هو أيضا السبب في أنني أحب الخيار .! الآن يمكنك الحصول على PHB لكتابة الاختبارات بالنسبة لك حسنا، ربما لا تماما على ما يرام، لكنها قريبة!)

Answer 6

و"PS: مدير أعمالي يقول أن الطريقة الوحيدة التي سوف تحصل لي تعزيزها ما اذا كان يمكنني الحصول على فريق لTDD / BDD"

والطريقة الواقعية الوحيدة للحصول على فريق أن يفعل شيئا (من دون قتل لكم في هذه العملية) هو أن نبين لهم بوضوح انه سيستفيد منهم لتغيير عاداتهم. وبعبارة أخرى، كتابة التعليمات البرمجية. الكثير من التعليمات البرمجية. طن من التعليمات البرمجية. وبعد ذلك عندما البريد الإلكتروني حاسم يصل أن يغير مواصفات جذريا، وتبين لهم أنه يمكنك تغيير التعليمات البرمجية الخاصة بك بسهولة مع إعادة الهيكلية وماذا يكون أسوأ لأنك كنت إعداد لأنه مع الاختبارات الخاصة بك في المكان. وكان شريط أخضر، الإختراق الإختراق الإختراق، شريط أحمر !!!!، الإختراق الإختراق الإختراق، شريط أخضر، العودة إلى ديارهم.

وقراءة كتاب كنت بيكام عن اختبار تصميم يحركها. تبدأ الاختبارات ومن ثم القيام التعليمات البرمجية. الحصول على بناء الخادم التوالي التي تدير الاختبارات! لا تحتاج بعد التمديد يكون ذلك للفريق ككل - تفعل ذلك لنفسك، وتبين لهم أنه يساعد

والوعظ يزعج فقط المواطنين:)

Answer 7

لقد تم القيام TDD لبضع سنوات, ولكن في الآونة الأخيرة لقد بدأت أبحث أكثر في BDD طريقة القيادة تصميمي والتنمية.الموارد التي ساعدتني على البدء في BDD كان أول فورموست دان شمال بلوق (في 'مؤسس' من BDD).نلقي نظرة على إدخال BDD.هناك أيضا "الرسمي" BDD ويكي في behaviour-driven.org مع بعض وظيفة جيدة تستحق القراءة.

الشيء الوحيد الذي وجدت من الصعب حقا عندما بدأت مع BDD (و لا تزال تجد من الصعب بعض الشيء) هو كيفية صياغة تلك السيناريوهات لجعلها مناسبة BDD.سكوت Bellware هو رجل المهرة في BDD (أو السياق-Spesification كما يحب عمله) و المادة السلوك التنمية المدفوعة باعتبارات في مدونة مجلة ساعدني كثيرا على فهم BDD طريقة التفكير وصياغة قصص المستخدم.

وأود أن نوصي أيضا على TekPub سكرينكست السلوك تصميم يحركها مع Specflow روب Conery.مقدمة كبير إلى BDD إلى أداة (SpecFlow) جيد جدا مناسبة للقيام BDD في C#.

أما بالنسبة TDD الموارد هناك بالفعل الكثير من التوصيات الجيدة هنا.ولكن أريد فقط أن أشير إلى بعض الكتب التي أنا حقا أن يوصي;

• العمل بفعالية مع التعليمات البرمجية القديمة مايكل والريش.يجب أن يكون قراءة إذا كنت تعمل على التعليمات البرمجية القديمة (أليس كذلك؟) و ترغب في الحصول عليها تحت الاختبار
• فن اختبار وحدة:مع أمثلة .صافي قبل روي Osherove;إذا كنت جديدا على وحدة اختبار هذا على كتاب للحصول على انك بدأته
• اختبار مدفوعة التنمية:على سبيل المثال قبل كنت بيك;إذا كنت تعلم TDD لماذا لا الحصول عليه من المصدر نفسه ؟ كتاب جيد - من السهل قراءة الدعابة و أفكار عظيمة.
• رمز نظيفة:دليل البرمجيات رشيق الحرفية روبرت C.مارتن ، إذا كنت بيك يصف كيف من TDD يا عم بوب يصف أسبابه.

Answer 8

لبدء إجراء اختبار للوحدة، ثم قرأ حول كيفية القيام بذلك الحق الأخير تعليم فريقك كيفية TDD وحملهم على متن الطائرة - لأنه في تجربتي ليس هناك ما هو أكثر أهمية ثم القيام اختبار وحدة مع فريقك كله

وأنت أيضا في حاجة إلى عملية الإنشاء المناسبة - باستخدام ملقم وبناء من شأنه بناء التعليمات البرمجية وتشغيل testst بك أوصي باستخدام TeamCity (الحرة مع القيود)

وتعلم كيفية صحيحا وحدة الاختبارات جيدة هو الجزء الصعب - بعض منه ستعرف بنفسك (طالما أن تبقي اختبار وحدة) والباقي يمكنك التعلم من البحث في الإنترنت

.

وعليك ان تعرف كنت قد وصلت هدفك عندما NOT كتابة وحدة الاختبارات كجزء من التنمية سوف تبدو لك مجرد خطأ.

Answer 9

وحفظ ووسائل رشيقة أنك لا تباع تماما على أي طريقة معينة. إذا كنت تعمل على شيء حيث فوائد TDD لا يستحق كل هذا العناء (مثل القيام التعديلات التجربة والخطأ على واجهة سوينغ)، ثم لا تستخدم TDD.

Answer 10

لا أرى أن أي شخص لديه حقا عن ذلك هو TDD لا حول الاختبار.TDD-ing عن التعبير عن السلوك المتوقع قبل القيام صغيرة السلوكية-تغيير وتعديل.هذا يحسن إلى حد كبير تصميم يتيح التركيز بطريقة لم تعرف من قبل.يمكنك الحصول على اختبارات الذي يحمي مستقبل refactorings و 90% تغطية مجانا.

لمعرفة ذلك أود أن أقترح (يلخص ما قاله الآخرون ، إضافة واحدة من بلدي):

1. زيارة بلوق قراءة الكتب المذكورة أعلاه
2. الزوج مع شخص يتقن TDD
3. الممارسة

لا يمارس البولينج كاتا (ممارسة) على بلدي حوالي 20 مرة (حوالي 30 دقيقة لكل منهما) قبل أن بدأت ترى النور.بدأت من خلال تحليل العم بوب الوصف منه هنا.هناك مجموعة من الكاتا على codingdojo.org الموقع بما في ذلك الحلول والمناقشات.في محاولة منهم!

Answer 11

لاتخاذ اقتبس من نايك: فقط تفعل ذلك

وقطعة الثاني المشورة - لا تعتمد على واجهة شخص آخر. إرسال دائما، على مستوى كل فئة، إلى واجهة كنت ترغب موجودة - حتى كتابة محول إلى التنفيذ الفعلي عند الضرورة

وبالإضافة إلى ذلك، أجد أنه من المفيد تجنب القيم العائد على الطرق، والتفكير من قانون من حيث الرسالة يمر بدلا من المكالمات وظيفة.

وYMMV.

Answer 12

وقبل عام، كان لي فكرة بسيطة كيفية القيام TDD (ولكن يريد حقا أن (كيف محبطة))، وكان لم يسمع من BDD ... الآن أفعل على حد سواء بشكل إلزامي. لقد كنت في بيئة تطوير الصافية، وليس جافا، ولكن حتى أنا محل "F5 - تشغيل" زر مع ماكرو إما تشغيل خيار (BDD) أو MBUnit (TDD) اعتمادا إذا كانت الميزة / السيناريو أو المواصفات. لا المصحح إذا كان ذلك ممكنا. 1 $ في جرة إذا كنت تستخدم المصحح (المزاح (من نوع)).

وهذه العملية هي رهيبة جدا. الإطار نحن بالإضافة إلى ذلك باستخدام هو من أوراكل لقد أنعم الله أن تأتي عبر، واستيعاب المعلومات من وهذا الإطار هو / نستخدمها هي MavenThought.

وكل شيء يبدأ مع هذا الاضطراب. لدينا BDD هو على التوالى بزيادة الخيار ONTOP روبي الحديد.

وتقرير اخبارى:

والسيناريو: ....    ونظرا أفعل كذا ...
   عندما أفعل شيئا آخر ...    ثم تحدث الأشياء الرائعة ...

والسيناريو: ...

وهذا ليس وحدة اختبار نفسها، لكنه يدفع الميزة، السيناريو السيناريو، وبالتالي وحدة (اختبار) المواصفات .. لذلك عليك أن تبدأ على السيناريو، ومع كل خطوة تحتاج إلى إكمال في السيناريو هو يدفع TDD الخاص بك.

وعلى TDD لقد تم استخدام نوع من الاضطراب في الطريق، لأننا ننظر إلى سلوكيات SUT (النظام تحت الاختبار) يتطلب ويتم تحديد سلوك واحد حسب مواصفات (الدرجة "اختبار" الملف).

مثال:

وهنا هو مواصفات لسلوك واحد: عندما يتم إنشاء نظام تحت الاختبار

.

وهناك أكثر من مواصفات (ملف فئة C # When_blah_happens) للسلوك آخر عند تغيير الممتلكات، ولكن أن يتم فصل للخروج الى ملف منفصل.

using MavenThought.Commons.Testing;
using SharpTestsEx;

namespace Price.Displacement.Module.Designer.Tests.Model.Observers
{
    /// <summary>
    /// Specification when diffuser observer is created
    /// </summary>
    [ConstructorSpecification]
    public class When_diffuser_observer_is_created
        : DiffuserObserverSpecification
    {
        /// <summary>
        /// Checks the diffuser injection
        /// </summary>
        [It]
        public void Should_return_the_injected_diffuser()
        {
            Sut.Diffuser.Should().Be.SameInstanceAs(this.ConcreteDiffuser);
        }
    }
}

وربما هذا هو أبسط سلوك لSUT، لأنه في هذه الحالة عند إنشائه، يجب أن تكون ملكا الناشر نفس الناشر حقن. اضطررت الى استخدام الناشر الخرسانة بدلا من سخرية لأنه في هذه الحالة الناشر هو كور / وجوه المجال وليس لديها إخطار الملكية للواجهة. 95٪ من الوقت نشير إلى كافة التبعيات لدينا مثل إقلاع ()، بدلا من حقن الشيء الحقيقي.

وغالبا ما يكون لدينا أكثر من واحد [و] Should_do_xyz ()، وأحيانا قليلا لا بأس به من إعداد مثل ربما تصل 10 خطوط الإستئصال. هذا مجرد مثال بسيط جدا مع أي GivenThat () أو AndGivenThatAfterCreated () في ذلك المواصفات.

لإعداد كل مواصفات نحتاج عموما من أي وقت مضى فقط لتجاوز أساليب عدة مواصفات:

وGivenThat () ==> حدث ذلك قبل إنشاء SUT.

وCreatSut () ==> نحن لصناعة السيارات إنشاء وهمية للسوت مع StructureMap و 90٪ من الوقت لا تحتاج إلى تجاوز هذا، ولكن إذا كنت منشئ على حقن الخرسانة، لديك لتجاوز هذا.

وAndGivenThatAfterCreated () => يحدث هذا بعد إنشاء SUT.

وWhenIRun () => ما لم يكن هو [ConstructorSpecification] نستخدم هذا لتشغيل سطر واحد من التعليمات البرمجية التي هو السلوك نحن specifiying لSUT

وأيضا، إذا كان هناك سلوك مشترك من اثنين أو أكثر من المواصفات من نفس SUT، ونحن نتحرك في هذا specifcation قاعدة.

وكل ما فعله لتشغيل المواصفات هو تسليط الضوء عليه اسم، مثلا "When_diffuser_observer_is_created" واضغط F5، لنتذكر، بالنسبة لي F5 يدير مهمة الخليع إما الاختبار: ميزة [العلامة] إذا الخيار، أو اختبار: فئة [SUT ]. من المنطقي بالنسبة لي لفي كل مرة تقوم بتشغيل المصحح انها رمي بعيدا، يتم إنشاء أي رمز (يا ويكلف $ 1 (يمزح)).

وهذا هو وسيلة نظيفة جدا من تحديد السلوك مع TDD وجود حقا، SUTs حقا بسيطة والمواصفات بسيطة. إذا حاولت ويكون رعاة البقر المبرمج وكتابة SUT كربي مع تبعيات الصعبة، وما إلى ذلك، سوف يشعر بالألم من محاولة القيام TDD والحصول على سئمت / التخلي أو لدغة الرصاصة ونفعل ذلك الحق.

وهنا يكمن SUT الفعلي. وصلنا القليل من الهوى واستخدام PostSharp لإضافة خاصية إبلاغ تغير على الناشر، لذلك ومن هنا جاءت Post.Cast <>. ومرة أخرى، ثاتي هو السبب في أنني حقن الخرسانة بدلا من موك. على أي حال، كما ترون سلوك المفقود محددة في مواصفات أخرى وعندما يتغير أي شيء على الناشر.

using System.ComponentModel;
using MavenThought.Commons.Events;
using PostSharp;
using Price.Displacement.Core.Products;
using Price.Displacement.Domain;

namespace Price.Displacement.Desktop.Module.Designer.Model.Observers
{
    /// <summary>
    /// Implementation of current observer for the selected product
    /// </summary>
    public class DiffuserObserver : AbstractNotifyPropertyChanged, IDiffuserObserver
    {
        /// <summary>
        /// gets the diffuser
        /// </summary>
        public IDiffuser Diffuser { get; private set; }

        /// <summary>
        /// Initialize with a diffuser
        /// </summary>
        /// <param name="diffuser">The diffuser to observe</param>
        public void Initialize(IDiffuser diffuser)
        {
            this.Diffuser = diffuser;
            this.NotifyInterface().PropertyChanged += (x, e) => this.OnPropertyChanged(e.PropertyName);
        }

        /// <summary>
        /// Gets the notify interface to use
        /// </summary>
        /// <returns>The instance of notify property changed interface</returns>
        protected INotifyPropertyChanged NotifyInterface()
        {
            return Post.Cast<Diffuser, INotifyPropertyChanged>((Diffuser)Diffuser);
        }
    }
}

في الختام، هذا BDD أسلوب / TDD من الصخور التنمية. استغرق الأمر سنة واحدة ولكن أنا الكلي تحويل وسيلة للحياة. لم أكن قد تعلمت هذا بمفردي. التقطت كل شيء من أوراكل http://orthocoders.com/ .

والأحمر أو الحبة الزرقاء، والخيار لك.