Kullanıcı Öykü için yeni kod yazma

Visual Studio Uygulama Yaşam Döngüsü Yönetimi'nin (ALM) ve Team Foundation Sunucusu'nun (TFS) yeni bir kullanıcısı mısınız?Uygulamanızı oluşturmak için bu araçların en son sürümlerini kullanarak sizin ve ekibinizin en yüksek faydayı nasıl kazanabileceğinizi merak ediyor musunuz?

Öyleyse bu iki bölüm eğitimini adım adım takip edin ve Fabrikam Fiber adlı kablolu televizyon ve ilgili hizmetleri sağlayan hayali şirketin iki geliştiricisi olan Peter ve Julia'nın hayatlarındaki bir günü takip edin.Bu sayede Visual Studio ve TFS'yi kullanarak nasıl bir kodu güncelleştirebileceğinize ve kullanıma alacağınıza, yarıda kalan bir işi nasıl askıya alacağınıza, kod incelemesi için nasıl istek yollayacağınıza, değişikliklerinizi nasıl iade edeceğinize ve diğer görevleri nasıl gerçekleştireceğinize dair örnekleri göreceksiniz.

Şu ana kadarki öykü

Ekip geçenlerde Uygulama Yaşam Döngüsü Yönetimi (ALM) için Visual Studio'ya ve Team Foundation Sunucusu'na uyarlamaya başladı.Kendi sunucularını ve istemci makinelerini kurdular, biriktirme listesi hazırladılar, yinelemeyi planladılar ve bir uygulamayı geliştirmeye başlamak için diğer gerekli planlamaları tamamladılar.

Bu bölüme genel bakış

Peter kısaca kendi biriktirme listesini inceler ve bugün çalışacağı görevi seçer.Geliştirmeyi planladığı kod için birim sınamalarını yazar.Genellikle, bir saat içinde birkaç kez testleri çalıştırır, giderek daha ayrıntılı testler yazar ve sonra bu testleri geçebilen bir kod yazar.Genellikle kodunun arabirimi hakkında, yazdığı metodu kullanacak olan iş arkadaşlarıyla görüşür.

[!NOT]

Bu konuda tartışılan Çalışmam ve Kod Kapsamı özellikleri yalnızca Visual Studio Premium ve Visual Studio Ultimate içinde kullanılabilir.

Bu konuda

• Kişisel biriktirme listenizi gözden geçirin ve işe başlamak için görevleri hazırlayın.

• İlk birim sınamasını oluşturun

• Yeni kod için bir koçan oluşturun

• İlk testi çalıştırın

• API'yı kabul edin

• Kırmızı, Yeşil, Yeniden Düzenleme ...

• Kod Kapsamı

• Ne zaman hazırız?

• Değişiklikleri iade edin

Kişisel biriktirme listenizi gözden geçirin ve işe başlamak için görevleri hazırlayın.

Bir Ekip Gezgini'nde, Peter Çalışmam sayfasını açar.Takım geçerli sprint sırasında Peter'ın fatura durumu, ürün biriktirme listesindeki yüksek öncelikli öğesi üzerinde çalışacağını kabul etmiştir.Peter yüksek öncelikli biriktirme listesinin öğesinin alt öğesinin görevi olan matematik işlevlerini gerçekleştirerek başlamaya karar verir.Bu görevi Kullanılabilir Çalışma Öğeleri listesinden Devam Eden Çalışma Öğeleri & Değişiklikler listesine sürükler.

Kişisel biriktirme listesini gözden geçirme ve işe başlamak için görevleri hazırlama

1. Ekip Gezgini'nde:

   1. Çalışmak istediğiniz ekip projesine bağlı değilseniz, ekip projesine bağlanın.

   2. Önce Ana Sayfa 'yı seçin ve ardından Çalışmam öğesini seçin.

2. Bir Çalışmam sayfasında, görevleri Kullanılabilir Çalışma Öğeleri listesinden Devam Eden Çalışma Öğeleri bölümüne sürükleyin.

   Ayrıca Kullanılabilir Çalışma Öğeleri listesinden bir görev seçebilirsiniz ve ardından Başlat'ı seçebilirsiniz.

Artan Çalışma Planı Taslağı

Peter, genellikle kodu bir dizi küçük adımlarla geliştirir.Her adım genellikle bir saatten daha uzun sürmez ve en az on dakika sürebilir.Her adımda, yeni bir birim sınaması yazar ve geliştirdiği kodu değiştirir. Böylece kod, yazmış olduğu testlerin yanı sıra yeni testlerden de geçer.Bazen yeni testi kodu değiştirmeden önce yazar ve bazen de testi yazmadan önce kodu değiştirir.Bazen kendisi yeniden düzenler.Diğer bir deyişle, kodu yeni testler eklemeden iyileştirir.O, hiçbir zaman geçen bir testi değiştirmez. Eğer değiştiriyorsa, testin gereklilikleri doğru temsil etmediğine karar vermiştir.

Her küçük adımın sonunda, kodun alanıyla ilgili tüm birim sınamalarını çalıştırır.Her testten geçinceye kadar, adımı tam olarak dikkate almaz.

Ancak, tüm görev bitinceye kadar Team Foundation Sunucusu'nda kodu denetlemez.

Peter bu dizinin küçük adımları için kaba bir plan yazar.Çalıştığı sürece, tam ayrıntıların ve sonrakilerin sırasının muhtemelen değişeceğini bilir.Kendisinin bu belirli görev için hazırladığı ilk adım listesi aşağıdadır:

1. Test metodu koçanı oluşturun— diğer bir deyişle, metodun imzası.

2. Belirli bir genel durumu karşılayın.

3. Geniş kapsamı sınayın.Kodun büyük bir değer aralığı için doğru biçimde yanıt verdiğinden emin olun.

4. Negatif üzerinde özel durum.Yanlış parametrelerle düzgün bir şekilde ilgilenin.

5. Kod kapsamı.En az kodun 80%'inin birim sınamalarında uygulandığından emin olun.

Onun bazı iş arkadaşları bu tür bir planı kendi test kodlarında açıklama olarak yazar.Diğerleri sadece kendi planlarını ezberler.Peter, Görev iş öğesinin Açıklama alanına bu adım listesini yazmayı yararlı bulur.Eğer daha acil bir göreve geçici olarak geçiş yapması gerekiyorsa, geri döndüğünde listeyi nerede bulacağını bilir.

İlk birim sınamasını oluşturun

Peter, birim sınamasını oluşturarak başlar.Birim sınamasıyla başlar çünkü yeni sınıfını kullanan kodun örneğini yazmak ister.

Bu, sınıf kitaplığı için sınadığı ilk birim sınamasıdır ve böylece yeni bir birim test projesi oluşturur.O, Yeni Proje iletişim kutusunu açar ve Visual C#, Test 'i ve ardından Birim Test projesi'ni seçer.

Birim test projesi, örneğini yazabileceği bir C# dosyasını sağlar.Bu aşamada, sadece kendi yeni metotlarından birinin nasıl çağrılacağını göstermek istiyor:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Fabrikam.Math.UnitTest
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        // Demonstrates how to call the method.
        public void SignatureTest()
        {
            // Create an instance:
            var math = new Fabrikam.Math.LocalMath();

            // Get a value to calculate:
            double input = 0.0;

            // Call the method:
            double actualResult = math.SquareRoot(input);

            // Use the result:
            Assert.AreEqual(0.0, actualResult);
        }
    }
}

Test metodunda bu örneği yazar. Çünkü bu kodu yazdığı esnada, örneğin çalışmasını istiyor.

Birim test projesi ve metotları oluşturma

Genellikle sınanan her proje için yeni bir test projesi oluşturun.Bir test projesi zaten varsa, yalnızca yeni test metotlarını ve sınıfları ekleyebilirsiniz.

Bu yordam Visual Studio Birim Testi Çerçevesi'ni kullanır, ancak diğer sağlayıcılardan çerçeveler de kullanabilirsiniz.Uygun bağdaştırıcıyı yüklediğinizde, Test Gezgini diğer çerçevelerle de eşit derecede iyi çalışır.

• Henüz yoksa, bir Test Projesi oluşturun.

  • Bir Yeni Proje iletişim kutusunda, Visual Basic, Visual C++ veya **Visual C#**gibi bir dil seçin.Önce Test 'i ve sonra Birim Test projesi'ni seçin.

• Testlerinizi sağlanan test sınıfına ekleyin.Her birim sınaması bir metottur.

  Her birim testi TestMethod özniteliği tarafından eklenmelidir ve birim sınaması metodunun parametresi olmamalıdır.Birim test metodu için istediğiniz herhangi bir adı kullanabilirsiniz:

          [TestMethod]
          public void SignatureTest()
          {...}
  

      <TestMethod()>
      Public Sub SignatureTest()
      ...
      End Sub
  

• Her test metodu, başarılı olup olmadığını belirtmek için Assert sınıfının bir metodunu çağırmalıdır.Genellikle, bir işlemin beklenen ve gerçek sonuçlarının eşit olduğundan emin olun:

  Assert.AreEqual(expectedResult, actualResult);
  

  Assert.AreEqual(expectedResult, actualResult)
  

• Test metotlarınız TestMethod özniteliğine sahip olmayan sıradan metotları çağırabilir.

• Testlerinizi birden fazla sınıf içinde düzenleyebilirsiniz.Her sınıf TestClass özniteliği tarafından eklenmelidir.

  [TestClass]
  public class UnitTest1
  { ... }
  

  <TestClass()>
  Public Class UnitTest1
  ...
  End Class
  

C++'ta birim sınamasını nasıl yazacağınıza dair daha fazla bilgi için, bkz: C++ için Microsoft Birim Test Çerçevesi ile C/C++ için Birim Testleri Yazma.

Yeni kod için bir koçan oluşturun

Daha sonra Peter, yeni kodu için bir sınıf kitaplığı projesi oluşturur.Artık geliştirme aşamasındaki kod için bir proje ve birim sınamaları için bir proje vardır.Geliştirme aşamasındaki kod için test projesinden bir proje başvurusu ekler.

Yeni projede, en azından testi başarıyla yapılandırmaya izin verebilecek metodun asgari sürümünü ve yeni sınıfı ekler.Bunu yapmanın en hızlı yolu, testteki çağrıdan sınıf ve metot koçanı oluşturmaktır.

        public double SquareRoot(double p)
        {
            throw new NotImplementedException();
        }

Testlerden sınıflar ve metotlar oluşturmak

İlk olarak henüz yoksa, yeni sınıfa eklemek istediğiniz projeyi oluşturun.

Bir sınıf oluşturmak için

1. Oluşturmak istediğiniz sınıf örneğinin üzerine imleci getirin, örneğin LocalMath. Kısayol menüsünden Kodu Üret, Yeni tür 'ü seçin.

2. Bir Yeni Tür iletişim kutusunda, Proje 'yi sınıf kütüphane projesi olarak ayarlayın.Bu örnekte Fabrikam.Math şeklindedir.

Metodu oluşturmak için

• İmleci metot çağrısının üzerine getirin, SquareRoot.Kısayol menüsünden Kodu üret, Metot Koçanı 'nı seçin.

İlk testi çalıştırın

Peter CTRL + R, T tuşuna basarak testi çalıştırır. Test sonucu kırmızı Başarısız göstergeyi gösterir ve test Başarısız Testlerlistesi altında görünür.

Koda basit bir değişiklik yapar:

       public double SquareRoot(double p)
        {
            return 0.0;
        }

Testi yeniden çalıştırır ve geçer:

Birim sınamalarını çalıştırmak için

• Bir Test menüsünden, Çalıştır, Tüm Testler'i seçin.

  -veya-

• Test Gezgini açıksa, Tümünü Çalıştır'ı seçin.

  - veya -

• İmleci bir test kod dosyasına getirin ve CTRL + R, T'ye basın.

• Test Başarısız Testler 'in altında görünürse:

  Testi , örneğin çift tıklatarak, açın.

  Testin başarısız olduğu nokta görüntülenir.

Testlerin tam bir listesini görmek için , Tümünü Göster'i seçin.Özete dönmek için GİRİŞ görünümünü seçin.

Test sonucunun ayrıntılarını görmek için: testini Test Gezgini'nde seçin.

Bir testin koduna gitmek için, Test Gezgini'nde teste çift tıklayın ya da kısayol menüsünden Testi Aç 'ı seçin.

Bir testte hata ayıklamak için: bir veya birkaç testin kısayol menüsünü açın, sonra Seçilen Testlerde Hata Ayıkla'yı seçin.

Çözümü oluşturduğunuz zaman arka planda testleri çalıştırmak için, , Testleri Yapılandırmadan sonra Çalıştır'a geçiş yapın.Daha önce başarısız olan testler ilk önce çalışır.

Arabirimi Kabul Edin

Peter Lync üzerinden iş arkadaşı Julia'yı çağırır ve kendi ekranını paylaşır.Julia, Peter'ın bileşenini kullanacaktır.Peter ilk örneğini gösterir.

Julia örneğin iyi olduğunu düşünür fakat "Birçok işlev testi geçebilir." yorumunu yapar.

Peter şöyle yanıtlar: "İlk testin amacı işlevin parametrelerinin ve adının doğru olduğundan emin olmaktır.Şimdi bu işlevin ana gereksinimini yakalayan bir test yazabiliriz."

Birlikte aşağıdaki testi yazarlar:

  
      [TestMethod]
        public void QuickNonZero()
        {
            // Create an instance to test:
            LocalMath math = new LocalMath();

            // Create a test input and expected value:
            var expectedResult = 4.0;
            var inputValue = expectedResult * expectedResult;

            // Run the method:
            var actualResult = math.SquareRoot(inputValue);

            // Validate the result:
            var allowableError = expectedResult/1e6;
            Assert.AreEqual(expectedResult, actualResult, allowableError,
                "{0} is not within {1} of {2}", actualResult, allowableError, expectedResult);
        }

İpucu

Bu işlev için, Peter ilk olarak özellikler için birim sınamasını yazdığı ve ardından testi karşılayan kodu yazdığı İlk Test Geliştirici'sini kullanır.Diğer durumlarda, bu testin pratik olarak gerçekçi olmadığını anlar, bunun yerine, kodu yazdıktan sonra testi yazar.Ancak birim sınamalarını yazmanın çok önemli olduğunu dikkate alır — koddan önce ya da sonra olsa da — çünkü testler kodu kararlı tutar.

Kırmızı, Yeşil, Yeniden Düzenleme...

Peter, sürekli olarak bir döngüyü takip eder. Bu; test yazdığı ve başarısız olduğunu onayladığı, testi geçebilen bir kodu yazdığı ve ardından yeniden düzenlemeyi dikkate aldığı bir döngüdür. Yeniden düzenleme ise testleri değiştirmeden kodu iyileştirmektir.

Kırmızı

Peter, Julia ile birlikte oluşturduğu yeni testi çalıştırmak için CTRL+R, T 'ye basar.Peter herhangi bir testi yazdıktan sonra, her zaman testi geçebilen kodu yazmadan önce onu çalıştırarak başarısız olduğuna emin olur.Bu, yazdığı bazı testlerde onaylamaları yerleştirmeyi unuttuktan sonra öğrendiği bir uygulamadır.Hata sonucunu görme; testi geçmesini sağladığında, test sonucunun bir gereksinimi doğru bir şekilde karşıladığına emin olmasını sağlar.

Diğer yararlı uygulama ise Testleri Yapılandırmadan sonra Çalıştır 'ı ayarlamaktır.Bu seçenek, her seferinde çözümü yapılandırdığınızda testleri arka planda çalıştırır. Böylece kodunuzun test durumuna dair sürekli bir raporunuz olur.Peter ilk başta bunun Visual Studio yanıtlamasını yavaşlatacağı konusunda şüpheliydi, ancak bu durumun nadiren gerçekleştiğini anlar.

Yeşil

Peter geliştirdiği kod metodunu ilk girişimde yazar:

    public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate;
                estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }
        

Peter testleri yeniden çalıştırır ve tüm testler geçer:

Yeniden Düzenleme

Artık kod ana işlevini gerçekleştirir ve Peter koda bakarak onun performansını iyileştirecek veya gelecekte değiştirmesini kolaylaştıracak yollar bulur.Döngüde yapılan hesaplamaların sayısını azaltabileceğini fark eder

public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate; 
                estimate = (estimate + x / estimate) / 2;
                //was: estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }

Testlerin hala geçtiğini doğrular:

İpucu

Kodunu geliştirirken yaptığınız her değişiklik bir yeniden düzenleme ya da bir uzantı olmalıdır: Yeniden düzenleme, yeni işlevsellik eklemediğinizden dolayı testleri değiştirmediğiniz anlamına gelir. Uzantı, var olan ve yeni testleri geçmek için kodda gerekli değişikler yapmak ve yeni testler eklemek anlamına gelir. Değiştirdiğiniz gereksinimler için var olan bir kodu güncelleştiriyorsanız, artık geçerli gereksinimleri temsil etmeyen eski testleri de silmeniz gerekir. Başarılı olan testleri değiştirmekten kaçının.Bunun yerine yeni testler ekleyin.Yalnızca gerçek bir gereksinimi gösteren testleri yazın. Her değişiklikten sonra testleri çalıştırın.

... ve yinele

Peter kendi dizi uzantısı ve adımlar, yeniden düzenleme, kaba bir kılavuz olarak kendi küçük adımların listesini kullanmaya devam eder.O, her uzantıdan sonra bir yeniden düzenlemeyi gerçekleştirmez ve bazenleri birden fazla yeniden düzenleme adımını art arda gerçekleştirir.Koda yaptığı her değişiklikten sonra birim sınamalarını çalıştırır.

Bazen kodlara yeni değişiklikler gerektirmeyen testleri ekler, fakat bu eklentiler kodların doğru çalıştığına emin olmasını sağlar. Örneğin, işlevin geniş bir girdi aralığında çalıştığından emin olmak ister.Bunun gibi, daha fazla test yazar:

        [TestMethod]
        public void SqRtValueRange()
        {
            LocalMath math = new LocalMath();
            for (double expectedResult = 1e-8;
                expectedResult < 1e+8;
                expectedResult = expectedResult * 3.2)
            {
                VerifyOneRootValue(math, expectedResult);
            }
        }
        private void VerifyOneRootValue(LocalMath math, double expectedResult)
        {
            double input = expectedResult * expectedResult;
            double actualResult = math.SquareRoot(input);
            Assert.AreEqual(expectedResult, actualResult, expectedResult / 1e6);
        }

Bu test ilk çalıştığında geçer:

Sonucun bir hata olmadığından emin olmak için, geçici olarak teste küçük bir hata tanıtarak testin başarısız olmasını sağlar.Başarısızlığı gördükten sonra, onu giderir.

İpucu
Her zaman, testi geçmeden önce testin başarısız olmasını sağlayın.

Özel Durumlar

Peter artık olağanüstü girdiler için testleri yazmaya başlar:

[TestMethod]
        public void RootTestNegativeInput()
        {
            LocalMath math = new LocalMath();
            try
            {
                math.SquareRoot(-10.0);
            }
            catch (ArgumentOutOfRangeException)
            {
                return;
            }
            catch
            {
                Assert.Fail("Wrong exception on negative input");
                return;
            }
            Assert.Fail("No exception on negative input");
        }

Bu test kodu bir döngüye koyar.Test Gezgini'ndeki İptal düğmesini kullanmalıdır.Bu, kodu 10 saniye içinde sonlandırır.

Peter, yapı sunucusunda bir sonsuz döngünün gerçekleşmeyeceğinden emin olmak ister.Sunucu tam çalışmaya bir zaman aşımı uygulasa da, bu çok uzun bir zaman aşımıdır ve önemli gecikmeye neden olabilir.Bu nedenle, açık zaman aşımını bu teste ekler:

        [TestMethod, Timeout(1000)]
        public void RootTestNegativeInput()
        {...

Açık zaman aşımı testi başarısız yapar.

Peter, daha sonra bu olağanüstü durumla başa çıkmak için kodu güncelleştirir:

       public double SquareRoot(double x)
        {
            if (x <= 0.0) 
            {
                throw new ArgumentOutOfRangeException();
            }

Gerileme

Yeni test geçer, ancak bir gerileme vardır.Geçen test artık başarısız olur:

Peter hatayı bulur ve giderir:

      public double SquareRoot(double x)
        {
            if (x < 0.0)  // not <=
            {
                throw new ArgumentOutOfRangeException();
            }

O giderildikten sonra tüm testler geçer:

İpucu
Koda yaptığınız her değişiklikten sonra tüm testlerin geçtiğinden emin olun.

Kod kapsamı

Kendi çalışmasındaki aralıklarda ve son olarak kodu iade ettiğinde, Peter bir Kod Kapsamı raporunu edinir.Bu, kodun ne kadarının kendi testleri tarafından uygulandığını gösterir.

Peter'ın takımı en az % 80 kapsamı amaçlar.Oluşturulan kod için bu gereksinimi esnekleştirirler. Çünkü bu türdeki bir kod için yüksek kod kapsamını elde etmek zor olabilir.

İyi bir kapsama, bileşenin tüm işlevselliğinin test edilmesini ve kodun her girdi değerleri aralığı için çalışacağını garanti etmez.Yine de, kod satırları ve bileşenin davranış alanı kapsamı arasında oldukça yakın bir bağıntı vardır.Bu nedenle, iyi kapsama ekibin sınamaları gereken çoğu davranışı sınadıklarına emin olmalarını sağlar.

Kod kapsamı raporu almak için Testler menüsünden Çalıştır, Tüm Testler için Kod Kapsamını Çözümle'yi seçin.Sonra tüm testleri yeniden çalıştırın.

Peter toplam %86 'lık bir kapsam alır.Raporda toplamı genişlettiğinde, geliştirdiği kodun 100% kapsamı olduğu görünür.Bu çok tatmin edicidir. Çünkü önemli puan test altındaki kod içindir.Kapsamda olmayan bölümler kendi testleri içindedir.Bir Kod Kapsamı Renklerini Göster düğmesine geçiş yaparak, Peter, test kodunun hangi bölümlerinin uygulanmadığını görebilir.Ancak, bu bölümlerin kapsama için önemli olmadığına karar verir. Çünkü bunlar test kodu içindedir ve sadece hata algılandığında kullanılabilir.

Belirli bir testin belirli kod dallarına ulaştığını doğrulamak için Kod Kapsamı Renklerini Göster 'i ayarlayın ve ardından kısayol menüsünden Çalıştır komutunu kullanarak tekli testi çalıştırın.

Ne zaman hazırız?

Peter, şunu karşılayana kadar kodu küçük adımlarla güncelleştirmeye devam eder:

• Kullanılabilir tüm birim sınamaları geçer.

  Birim sınamaları kümesinin çok büyük olduğu bir projede, geliştiricinin tümünü çalıştırmak için beklemesi pratik olmayabilir.Bunun yerine, proje tüm otomatikleştirilmiş testlerin her bir iadeli raf kümesi için, kaynak ağacına birleştirilmeden önce çalıştırıldığı geçitli iadeyi çalıştırır.Çalıştırma başarısız olursa iade reddedilir.Bu, geliştiricinin kendi makinesinde birim sınamalarının asgari kümesini çalıştırmasını sağlar, ve ardından yapıyı bölme riskini çalıştırmadan diğer işlerin devamını sağlar.Daha fazla bilgi için bkz. Değişiklikleri doğrulamak için geçitli iade etme yapı işlemini kullanma.

• Kod kapsamı takımın standartlarını karşılar. % 75 genel bir proje gereksinimidir.

• Onun birim sınamaları, normal ve olağanüstü girdileri de dahil ederek, her yönüyle gerekli davranışın benzetimini yapar.

• Onun kodu kolay anlaşılır ve genişletilebilirdir.

Tüm bu ölçütler karşılandığında, Peter kaynak denetiminden kodunu kontrol etmeye hazırdır.

Birim sınamaları ile kod geliştirme prensipleri

Peter, kodu geliştirirken aşağıdaki prensipleri takip eder:

• Birim sınamalarını kod ile birlikte geliştirin ve geliştirme esnasında bunları sık sık çalıştırın.Birim sınamaları bileşenlerinizin belirtimlerini temsil eder.

• Test hatalı olmadığı sürece veya gereksinimler değiştirilmediği sürece, birim sınamalarını değiştirmeyin.Kodun işlevselliğini genişlettikçe yavaş yavaş yeni testler ekleyin.

• Kodunuzun test kapsamının en az 75% olmasını hedefleyin.Kod kapsamını sonucuna kaynak kodunu iade etmeden önce ve aralıklarda bakın.

• Kodun yanı sıra birim sınamalarınızı iade edin, böylece sürekli veya düzenli sunucu yapılarında çalışırlar.

• Pratik olduğunda, her işlevsellik parçası için, ilk önce birim sınamasını yazın.Onu karşılayan kodu geliştirmeden önce bunu yapın.

Değişiklikleri iade edin

Değişiklikleri iade etmeden önce, Peter tekrar Lync kullanarak iş arkadaşı Julia ile ekranını paylaşır. Böylece Julia oluşturulanları gayri ve etkileşimli bir şekilde gözden geçirebilir.Testler tartışmanın odağı olmaya devam eder. Çünkü Julia öncelikli olarak kodun nasıl çalıştığıyla değil, kodun ne yaptığıyla ilgilenmektedir.Julia, Peter'ın yazdıklarının onun gereksinimlerini karşıladığını kabul eder.

Peter, kod ve test dahil olmak üzere tüm yaptığı değişiklikleri iade eder ve tamamladığı görev ile bunları ilişkilendirir.İade, ekibin CI Yapı işlem yapılandırmasını kullanarak, ekibin otomatik ekip yapı sistemini Peter'ın değişiklikleriyle doğrulamak için sıraya alır.Bu yapı işlemi kod tabanındaki hataları en aza indirmek için ekibe, yapılandırarak ve sınayarak yardımcı olur—kendi geliştirme bilgisayarların ayrı temiz bir ortamda—ekibin yaptığı her değişiklik.

Yapı tamamlandığında Peter'a bildirilir.Yapı sonuçları penceresinde, yapının başarılı olduğunu ve tüm testlerin geçtiğini görür.

Değişiklikleri iade etmek için

1. Menü çubuğunda View 'ı ve Ekip Gezgini 'ni seçin.

2. Bir Ekip Gezgini'ninde, Ana Sayfa 'yı seçin ve ardından Çalışmam'ı seçin.

3. Bu Çalışmam sayfasında, İade Et'i seçin.

4. Aşağıdakilerden emin olmak için Bekleyen Değişiklikler sayfasının içeriğini gözden geçirin:

   • Tüm ilgili değişiklikler, Dahil Edilen Değişiklikler içinde listelenir

   • Tüm ilgili iş öğeleri, İlgili İş Öğeleri içinde listelenir.

5. Değiştirilmiş dosya ve klasörlerin sürüm denetim geçmişine baktıklarında takımınızın bu değişikliklerin amacını anlamasına yardımcı olmak için bir Yorum belirtin.

6. İade et'i seçin.

Kodu sürekli tümleştirmek için

Sürekli yapı tümleştirme işlemini tanımlama hakkında daha fazla bilgi için bkz: Bir CI yapısı kurma.Bu yapı işlemini ayarladıktan sonra, ekip yapısının sonuçları hakkında bildirilmeyi seçebilirsiniz.

Daha fazla bilgi için bkz. Yapıları çalıştırma, izleme ve yönetme.

Sonraki (İşi askıya alma, bir hatayı giderme ve kod incelemesini gerçekleştirme)