Test edilebilir PowerShell Kodunu Tasarlama

Kodunuzun sonunda Pester testini geçmesi gerekeceğini göz önünde bulundurarak, komut dosyalarınızı tamamlarken yardımcı olacaktır.

Bir şey kesin. Bugün PowerShell’de yazdığınız kod muhtemelen “teste hazır” değildir. Neden böyle söylüyorum Bunun nedeni, çoğumuz yalnızca işleri gerçekleştirmek için PowerShell kodu yazmamızdır. PowerShell geleneksel olarak “komut dosyası oluşturma” ile ilgili ve “yazılım geliştirme” ile ilgili değildir. Hayatlarımızı kolaylaştırmak ve devam etmek için geçici şeyler yapmak için senaryolar yazıyoruz. Ancak, Microsoft’un PowerShell’i tam olarak geride bırakması ve hatta bazı ürünlerin onunla yönetilmesi için zorlamasıyla insanlar, dile daha çok yatırım yapıyor ve kritik süreçleri korumak için komut dosyalarına ve modüllerine bağlıyorlar. Üretim sistemi sağlandığından emin olmak için bir parça kod başladıktan sonra, test yazmak için zaman gelir.

PowerShell için test yazmak için fiili standart Pester’tir . Zaten Pester’de enfiye yoksa, The Pester Book’a göz atmanızı tavsiye ederim. Bu büyük test ürünü hakkında bilmeniz gereken tüm ayrıntılara giriyor.

Diyelim ki Pester’in nasıl kullanılacağını biliyorsunuz, mevcut kodunuz için testler yazmaya başlıyoruz, ancak kısa sürede cesaretsizleşeceksiniz. Genellikle kodunuzun yazılma biçiminin Pester ile iyi çalışmadığını öğreneceksiniz. Mevcut kodlar için testler yazmaya çalışmak yerine, bir adım geriye gidip kodunuzun ilk etapta daha iyi yazılmış olup olmayacağına karar vermek her zaman iyi bir fikirdir.

Her şeyden önce, kodların Pester ile neredeyse test edilemez olduğu düşünülürken, diğer yöntemlerin de kullanışsız olduğunu ispatlamanın birçok yolu var.

Fonksiyonları Kullanın 

Tipik bir birim test taktikleri yapmak için Pester’ın “kontrol” edebilmesi gerekiyor. İyi testler yazmak için, hangi kod parçalarını test edeceğinizi ve ne zaman seçeceğinizi seçerek seçebilmelisiniz. Bunu Pester ile yapmanın aracı alay konusu yapıyor. Alay, mevcut işlevleri “üzerine yazmak” ve bunları kullanıcı tanımlı kodla değiştirmenize izin verir. Yani, Active Directory’de bilgisayar hesapları bulmak için bu gibi görünen bir kodunuz varsa, bu kodların yeniden biçimlendirilmesi gerekecek demektir.

$ Searcher = Yeni Arama: Nesne DirectoryServices.DirectorySearcher
$ Searcher.Filter = ‘(& (objectCategory = kişi) (anr = gusev))’
$ Searcher.SearchRoot = ‘LDAP: // OU = Dizüstü bilgisayarlar, OU = Bilgisayarlar, DC = konsolos , DC = com ‘
$ Searcher.FindAll ()

Yukarıdaki kodun değiştirilmesi gerekçesi, herhangi bir komutu kullanmamasından kaynaklanmaktadır. Bir nesne yaratıyor ve daha sonra nesnenin özelliklerini ve yöntemlerini kullanıyor. Pester bunu anlamıyor ve bu nedenle bu kod parçası için yararlı testler yazmak imkânsız olacaktı. Bunun yerine bunu Get-AdUser komutu gibi bir cmdlet kullanarak değiştiririz.

Get-AdComputer -Tanıklılık ‘gusev’

İkinci yöntem daha temiz ve sezgisel değil, aynı zamanda çok “Öngörülebilir”!

İşlevleri Kük

Tutun İşlevleri küçük tutmak her zaman iyi bir uygulamadır. Fonksiyonlar yalnızca küçük bir “şey” yapmalı ve büyük betik veya modüller inşa ederken bu fonksiyonlar birbirlerine bir miktar iş yapmak için çağrılacaktır. Bununla birlikte, tembel olabilmeniz için önce kodunuz için herhangi bir test oluşturmadıysanız ve işlevler oluşturduysanız, bu işlevler devasa olabilir. Yüzlerce satır uzunluğunda bazı işlevler gördüm ! Bu çok uzun bir yol. Onları mümkün olan kadar küçük tutmak iyi bir uygulamadır. Bu büyük işlevler için testler oluşturmaya başlayınca, bu “test etme konusu” nun ne kadar karmaşık hale geldiğini hayal kırıklığına uğratacaksınız demektir. Gerçekte, kodunuz ”

Örneğin, neredeyse hiç başka işlev referansına sahip olmayan buna benzer bir kurgusal işlev alın. Scripter, hemen hepsini yapmak için bu işleve bir sürü kod attı.

Işlevi Invoke-UserProvisioning {
param (
$ FirstName,
$ LastName
)
 

## AD hesabı

oluşturun

##
 

Exchange posta kutusunu oluşturun ##
 

Ana klasörü

oluşturun

## DHCP rezervasyonunuzu oluşturun ## ve açık ve ….
 

}

Yukarıdaki bu işlev, için testler yazmakta felaket olacak. Bir sürü alaycılık yapacak ve pek çok farklı değişkeni ele alacak. Bunun yerine, neden bu görev için ayrı işlevler oluşturup bunları bir betikte çağırarak bu sorunu çözmeyelim?

Fonksiyonu New-AcmeADUser {
param ()
}
 

fonksiyonu New-AcmeExchangeMailbox {
param ()
}
 

fonksiyonu New-AcmeHomeFolder {
param ()
}
 

fonksiyonu New-AcmeDhcpReservation {
param ()
}

Kabul ederseniz, bu birçok işleve bölünemez; ancak burada nereye gideceğimi görmelisiniz. İşlevlerinizi çiğneyin, bu nedenle sadece bir, kısaca görev yapıyorlar. Tek bir fonksiyonla okyanus kaynatmaya çalışmayın. Kod uzun vadede düzeltilemez ve testlerinizin oluşturulması zor değil aynı zamanda bakımı da zor olacak.