โครงการทดสอบ NUnit กับ Visual Studio 2008 สำหรับการทดสอบหน่วย? [ปิด]

ฉันจะเริ่มโครงการใหม่ในที่ทำงานและต้องการเข้าทดสอบหน่วย เราจะใช้ VS 2008, C # และ ASP.NET MVC ฉันกำลังมองหาการใช้ NUnit หรือโครงการทดสอบในตัวที่ VS2008 มี แต่ฉันเปิดให้ทำการค้นคว้าคำแนะนำอื่น ๆ ระบบหนึ่งดีกว่าระบบอื่นหรืออาจจะใช้ / เข้าใจง่ายกว่าระบบอื่นหรือไม่? ฉันกำลังมองหาการตั้งค่าโครงการนี้เป็น "แนวปฏิบัติที่ดีที่สุด" สำหรับความพยายามในการพัฒนาของเราในอนาคต

ขอบคุณสำหรับความช่วยเหลือและคำแนะนำใด ๆ !!

Daokตั้งชื่อโปรของโครงการทดสอบ VS2008 ทั้งหมดนี่คือโปรของ NUnit

• NUnit มีกรอบการเยาะเย้ย
• NUnit สามารถเรียกใช้ภายนอก IDE ซึ่งมีประโยชน์ถ้าคุณต้องการเรียกใช้การทดสอบบนเซิร์ฟเวอร์ที่ไม่ใช่ MS build เช่น CC.Net
• NUnit มีเวอร์ชั่นออกมามากกว่า visual studio คุณไม่ต้องรอเป็นปีสำหรับรุ่นใหม่และคุณไม่จำเป็นต้องติดตั้ง IDE เวอร์ชันใหม่เพื่อรับคุณสมบัติใหม่
• มีการพัฒนาส่วนขยายสำหรับ NUnit เช่นการทดสอบแถวเป็นต้น
• การทดสอบ Visual Studio ใช้เวลานานในการเริ่มต้นด้วยเหตุผลบางอย่าง นี้จะดีกว่าในปี 2008 แต่ก็ยังช้าเกินไปสำหรับรสนิยมของฉัน เรียกใช้การทดสอบอย่างรวดเร็วเพื่อดูว่าคุณไม่ได้หักอะไรบางอย่างอาจใช้เวลานานเกินไป NUnit กับ Testdriven.Net เพื่อทำการทดสอบจาก IDE นั้นเร็วกว่ามาก โดยเฉพาะอย่างยิ่งเมื่อทำการทดสอบเดี่ยว
  การติดต่อกับ Kjetil Klaussen เกิดจากการทดสอบ Visual Studio โดยใช้การทดสอบ MSTest ใน TestDriven.Net ทำให้ MSTest มีประสิทธิภาพเทียบเท่ากับ NUnit

กรอบการทดสอบหน่วยนั้นไม่สำคัญมากนักเพราะคุณสามารถแปลงคลาสการทดสอบด้วยไฟล์โครงการแยกต่างหากและการคอมไพล์แบบมีเงื่อนไข (เช่นนี้ VS-> NUnit):

 #if! NUNIT
  ใช้ Microsoft.VisualStudio.TestTools.UnitTesting;
 #อื่น
  ใช้ NUnit.Framework;
  ใช้ TestClass = NUnit.Framework.TestFixtureAttribute;
  ใช้ TestMethod = NUnit.Framework.TestAttribute;
  ใช้ TestInitialize = NUnit.Framework.SetUpAttribute;
  using TestCleanup = NUnit.Framework.TearDownAttribute;
  ใช้ TestContext = System.String;
  using DeploymentItem = NUnit.Framework.DescriptionAttribute;
 endif #

ปลั๊กอิน TestDriven.Net นั้นดีและไม่แพงมาก ... ด้วย VS2008 ธรรมดาเท่านั้นคุณต้องหาการทดสอบจากคลาสทดสอบหรือรายการทดสอบของคุณ ด้วย TestDriven.Net คุณสามารถรันการทดสอบโดยตรงจากชั้นเรียนที่คุณกำลังทดสอบ ท้ายที่สุดการทดสอบหน่วยควรบำรุงรักษาง่ายและใกล้กับผู้พัฒนา

ประโยชน์ / การเปลี่ยนแปลงของ VS2008 ชุดทดสอบหน่วยภายใน

1. รุ่น 2008 มีให้บริการในรุ่นมืออาชีพ (ก่อนที่จะต้องใช้เวอร์ชันแพงของ VS นี่เป็นเพียงการทดสอบหน่วยนักพัฒนาเท่านั้น) ซึ่งทำให้นักพัฒนาจำนวนมากมีตัวเลือกเพียงตัวเลือกเดียวสำหรับกรอบการทดสอบแบบเปิด / ภายนอก
2. API ในตัวรองรับโดย บริษัท เดียว
3. ใช้เครื่องมือเดียวกันเพื่อเรียกใช้และสร้างการทดสอบ (คุณสามารถเรียกใช้โดยใช้บรรทัดคำสั่งและ MSTest ด้วย)
4. การออกแบบที่เรียบง่าย (ไม่มีกรอบการทำงานเยาะเย้ย แต่นี่เป็นจุดเริ่มต้นที่ดีสำหรับโปรแกรมเมอร์หลาย ๆ คน)
5. ได้รับการสนับสนุนระยะยาว (ฉันยังจำได้ว่าเกิดอะไรขึ้นกับ nDoc ฉันไม่ต้องการผูกพันกับกรอบการทดสอบที่อาจไม่รองรับใน 5 ปี แต่ฉันยังถือว่า nUnit เป็นกรอบที่ยอดเยี่ยม)
6. หากใช้เซิร์ฟเวอร์มูลฐานของทีมเป็นแบ็กเอนด์ของคุณคุณสามารถสร้างไอเท็มงานหรือข้อบกพร่องด้วยข้อมูลการทดสอบที่ล้มเหลวอย่างง่าย

ฉันใช้ NUnit มา 2 ปีแล้ว ทั้งหมดเป็นเรื่องปกติ แต่ฉันต้องบอกว่าระบบยูนิตใน VS นั้นค่อนข้างดีเพราะอยู่ใน Gui และสามารถทำการทดสอบสำหรับฟังก์ชั่นส่วนตัวได้ง่ายขึ้นโดยไม่ต้องวุ่นวาย นอกจากนี้การทดสอบหน่วย VS ให้คุณครอบคลุมและสิ่งอื่น ๆ ที่ NUnit เพียงอย่างเดียวไม่สามารถทำได้

สิ่งหนึ่งที่น่ารำคาญเล็กน้อยสำหรับกรอบการทดสอบของ Visual Studio คือมันจะสร้างไฟล์ทดสอบที่เรียกใช้จำนวนมากซึ่งมีแนวโน้มว่าจะทำให้ไดเรกทอรีโครงการของคุณยุ่งเหยิงแม้ว่านี่จะไม่ใช่เรื่องใหญ่อะไร

นอกจากนี้หากคุณไม่มีปลั๊กอินเช่น TestDriven.NET คุณไม่สามารถดีบักการทดสอบหน่วย NUnit ของคุณ (หรือ MbUnit, xUnit ฯลฯ ) ภายในสภาพแวดล้อม Visual Studio อย่างที่คุณทำได้ด้วยกรอบการทดสอบ Microsoft VS ซึ่งสร้างขึ้นมา

ปิดหัวข้อเล็กน้อย แต่ถ้าคุณไปกับ NUnit ฉันสามารถแนะนำให้ใช้ReSharper - มันเพิ่มปุ่มบางปุ่มลงใน VS UI ที่ทำให้การเรียกใช้และการทดสอบการดีบักจาก IDE ทำได้ง่ายขึ้นมาก

รีวิวนี้ล้าสมัยเล็กน้อย แต่จะอธิบายในรายละเอียดเพิ่มเติม:

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx

XUnit เป็นไปได้อีกอย่างสำหรับโครงการกรีนฟิลด์ มันอาจจะเป็นไวยากรณ์ที่ใช้งานง่ายกว่า แต่ไม่เข้ากันได้กับกรอบงานอื่น ๆ

http://www.codeplex.com/xunit

เนื้อหลักของฉันกับการทดสอบหน่วย VS เหนือ NUnit คือการสร้างการทดสอบ VS มีแนวโน้มที่จะฉีดรหัสที่สร้างขึ้นสำหรับการเข้าถึงสมาชิกส่วนตัว

บางคนอาจต้องการทดสอบวิธีการส่วนตัวของพวกเขาบางคนอาจไม่ได้นั่นคือหัวข้อที่แตกต่างกัน

ความกังวลของฉันคือเมื่อฉันเขียนการทดสอบหน่วยพวกเขาควรจะควบคุมอย่างมากดังนั้นฉันรู้ว่าสิ่งที่ฉันทดสอบและวิธีการทดสอบ หากมีรหัสที่สร้างขึ้นโดยอัตโนมัติฉันสูญเสียความเป็นเจ้าของไปบางส่วน

ฉันได้ทำ TDD บางอย่างโดยใช้ทั้งสองอย่าง (บางทีฉันอาจจะโง่เล็กน้อย) nUnit ดูเหมือนจะเร็วและง่ายกว่าสำหรับฉันมาก และเมื่อฉันพูดมากฉันหมายถึงมาก

ในการทดสอบ MS มีคุณสมบัติมากเกินไปทุกที่ - รหัสที่ทำการทดสอบจริงคือเส้นเล็ก ๆ ที่คุณอาจอ่านที่นี่และที่นั่น ความยุ่งเหยิงครั้งใหญ่ ใน nUnit รหัสที่ทำการทดสอบจะควบคุมคุณลักษณะดังที่ควรทำ

นอกจากนี้ใน nUnit คุณต้องคลิกที่การทดสอบที่คุณต้องการเรียกใช้ (การทดสอบทั้งหมดเดียวครอบคลุมการเรียนการประชุมหรือการแก้ปัญหา?) เพียงคลิกเดียว และหน้าต่างนั้นใสและใหญ่ คุณได้รับแสงสีเขียวและสีแดงที่ชัดเจน คุณรู้ว่าสิ่งที่เกิดขึ้นในสายตาเดียว

ใน VSTS รายการทดสอบนั้นติดอยู่ที่ด้านล่างของหน้าจอมันเล็กและน่าเกลียด คุณต้องดูสองครั้งเพื่อทราบว่าเกิดอะไรขึ้น และคุณไม่สามารถเรียกใช้การทดสอบเพียงหนึ่งเดียว (ดีฉันยังไม่ได้หา!)

แต่ฉันอาจจะผิดแน่นอน - ฉันเพิ่งอ่านประมาณ 21 โพสต์บล็อกเกี่ยวกับ "วิธีทำง่ายๆ TDD โดยใช้ VSTS" ฉันควรจะอ่านมากขึ้นคุณพูดถูก

สำหรับ nUnit ฉันอ่านมัน และฉันถูก TDDing ในวันเดียวกัน ด้วยความสนุกสนาน

อย่างไรก็ตามฉันมักจะรักผลิตภัณฑ์ของ Microsoft Visual Studio เป็นเครื่องมือที่ดีที่สุดที่นักพัฒนาสามารถซื้อได้ แต่การจัดการ TDD และรายการงานใน Visual Studio Team System แย่มากจริงๆ

ทั้งหมดที่ดีที่สุด ซิลแว็ง

ฉันได้รับข้อความว่า "โครงสร้างไฟล์ NUnit ยิ่งกว่า VSTest" ... แน่นอนถ้าคุณชอบโครงสร้างไฟล์ NUnit คุณสามารถใช้วิธีนี้ในวิธีอื่นเช่นนี้ (NUnit-> VS):

 #if !MSTEST
  using NUnit.Framework;
 #else
  using Microsoft.VisualStudio.TestTools.UnitTesting;
  using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
  using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
  using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
  using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
 #endif

หรือการแปลงอื่น ๆ ... :-) การใช้ที่นี่เป็นเพียงนามแฝงของคอมไพเลอร์

ก่อนอื่นฉันต้องการแก้ไขข้อความผิด: คุณสามารถเรียกใช้ msTest นอก Visual Studio โดยใช้บรรทัดคำสั่ง แม้ว่าเครื่องมือ CI หลายรายการเช่น TeamCity จะสนับสนุน NUnit ได้ดีขึ้น (อาจเปลี่ยนไปเนื่องจาก msTest เป็นที่นิยมมากกว่า) ในโครงการปัจจุบันของเราเราใช้ทั้งคู่และสิ่งที่แตกต่างกันอย่างมากที่เราพบคือ mstest ทำงานเป็น 32 บิตเสมอในขณะที่ NUnit ทำงานเป็นแบบทดสอบ 32 บิตหรือ 64 บิตซึ่งสำคัญหากรหัสของคุณใช้รหัสพื้นเมืองที่ขึ้นกับ 32/64

ฉันเริ่มต้นด้วย MSTest แต่เปลี่ยนด้วยเหตุผลง่าย ๆ เพียงข้อเดียว MSTest ไม่สนับสนุนการสืบทอดวิธีทดสอบจากชุดประกอบอื่น

ฉันเกลียดความคิดในการเขียนการทดสอบเดียวกันหลายครั้ง โดยเฉพาะอย่างยิ่งในโครงการขนาดใหญ่ที่วิธีการทดสอบสามารถทดสอบได้ 100 แบบ

NUnit ทำสิ่งที่ฉันต้องการอย่างเต็มที่ สิ่งเดียวที่ขาดหายไปกับ NUnit คือ Visual Studio Addin ซึ่งสามารถแสดงสถานะสีแดง / เขียว (เช่น VSTS) ของการทดสอบแต่ละครั้ง

.NET Framework Framework คำแนะนำและแพ็คเกจการทดสอบหน่วย. NET .

หากคุณกำลังพิจารณา MSTest หรือ nUnit ฉันขอแนะนำให้คุณดูที่ mbUnit เหตุผลของฉันคือ

1. TestDriven.Net เข้ากันได้ TestDriven.Net.ReRunWithDebugger ไม่มีสิ่งใดที่ผูกพันกับชุดแป้นพิมพ์
2. กรอบงาน Gallio Gallio เป็นนักวิ่งทดสอบอย่าง nUnits ข้อแตกต่างคือมันไม่สนใจว่าคุณเขียนการทดสอบใน nUnit, msTest, xUnit หรือ mbUnit พวกเขาทั้งหมดวิ่งหนี
3. ความเข้ากันได้กับ nUnit คุณสมบัติทั้งหมดใน nUnit ได้รับการสนับสนุนโดย mbUnit ฉันคิดว่าคุณไม่จำเป็นต้องเปลี่ยนคุณลักษณะของคุณ (จะต้องตรวจสอบว่า) เพียงแค่การอ้างอิงและการใช้งานของคุณ
4. ยืนยันการสะสม mbUnit มีกรณี Assert เพิ่มเติมรวมถึงคลาส CollectionAssert โดยทั่วไปคุณไม่จำเป็นต้องเขียนการทดสอบของคุณเองอีกต่อไปเพื่อดูว่ามี 2 คอลเลกชันที่เหมือนกันหรือไม่
5. การทดสอบเชิง Combinatorial มันจะไม่เจ๋งถ้าคุณสามารถจัดหาข้อมูลสองชุดและรับการทดสอบสำหรับการรวมกันของข้อมูลทั้งหมด มันอยู่ใน mbUnit

ตอนแรกฉันเลือก mbUnit เนื่องจากฟังก์ชั่น [RowTest .... ] และฉันไม่พบเหตุผลที่จะย้อนกลับ ฉันย้ายชุดทดสอบที่ใช้งานอยู่ทั้งหมดของฉันไปจาก nUnit และไม่เคยหันกลับมามอง ตั้งแต่นั้นมาฉันได้เปลี่ยนทีมพัฒนาสองทีมให้เป็นประโยชน์

เท่าที่ฉันรู้มีสี่กรอบสำหรับการทดสอบหน่วยกับ. NET วันนี้

• NUnit
• MbUnit
• MSTest
• xUnit

NUnit อยู่ข้างหน้าเสมอ แต่ช่องว่างได้ปิดในปีที่แล้ว ฉันยังคงชอบ NUnit ด้วยตัวเองโดยเฉพาะอย่างยิ่งเมื่อพวกเขาเพิ่มส่วนต่อประสานที่คล่องแคล่วกลับมาซึ่งทำให้การทดสอบสามารถอ่านได้

หากคุณเพิ่งเริ่มต้นกับการทดสอบหน่วยมันอาจไม่สร้างความแตกต่างมากนัก เมื่อคุณเร่งความเร็วคุณจะอยู่ในตำแหน่งที่ดีกว่าที่จะตัดสินว่ากรอบไหนดีที่สุดสำหรับความต้องการของคุณ

ฉันไม่ชอบกรอบการทดสอบ VS ในตัวเพราะมันบังคับให้คุณสร้างโครงการแยกต่างหากเมื่อเทียบกับการทดสอบของคุณเป็นส่วนหนึ่งของโครงการที่คุณกำลังทดสอบ

MSTest โดยพื้นฐานแล้ว NUnit ได้ทำใหม่เล็กน้อยด้วยคุณสมบัติใหม่บางอย่าง (เช่นการตั้งค่าการประกอบและการฉีกขาดไม่ใช่แค่การติดตั้งและระดับการทดสอบ) และการขาดบิตที่ดีที่สุดบางส่วน (เช่นไวยากรณ์ข้อ จำกัด 2.4 ใหม่) NUnit เป็นผู้ใหญ่มากขึ้นและมีการสนับสนุนจากผู้ขายรายอื่นมากขึ้น และแน่นอนว่ามันฟรีตลอดเวลา (ในขณะที่ MSTest ทำให้เป็นรุ่น Professional ของปี 2008 ก่อนหน้านั้นจะมี SKU ราคาแพงกว่า) โครงการ ALT.NET ส่วนใหญ่จะใช้

ต้องบอกว่ามีบาง บริษัท ที่ไม่เต็มใจที่จะใช้บางสิ่งบางอย่างที่ไม่มีฉลาก Microsoft อยู่และโดยเฉพาะอย่างยิ่งรหัส OSS ดังนั้นการมีกรอบการทดสอบอย่างเป็นทางการของ MS อาจเป็นแรงจูงใจที่ บริษัท เหล่านั้นจำเป็นต้องได้รับการทดสอบ และขอพูดตามตรงว่านี่คือการทดสอบที่สำคัญไม่ใช่เครื่องมือที่คุณใช้ (และใช้รหัสของ Tuomas Hietanenด้านบนคุณสามารถเปลี่ยนกรอบการทดสอบแทนได้)

ด้วยการเปิดตัวใน. NET 4.0 ของระบบรหัสสัญญาและความพร้อมใช้งานของตัวตรวจสอบแบบคงที่คุณจะต้องเขียนกรณีทดสอบน้อยลงในทางทฤษฎีและเครื่องมือเช่นPexจะช่วยระบุกรณีเหล่านั้น เกี่ยวข้องกับการสนทนานี้ถ้าคุณต้องการทดสอบหน่วยของคุณน้อยลงเพราะสัญญาของคุณครอบคลุมหางของคุณแล้วทำไมไม่เพียงแค่ไปข้างหน้าและใช้ชิ้นส่วนในตัวเพราะนั่นเป็นการพึ่งพาน้อยกว่าในการจัดการ ทุกวันนี้ฉันเป็นคนเรียบง่าย :-)

ดูสิ่งนี้ด้วย:

• Microsoft Pex - การทดสอบหน่วยอัตโนมัติ
• การสร้างยูนิตทดสอบด้วย Pex โดยใช้ Visual Studio 2010 และ C # 4.0

ฉันต้องการใช้กรอบการทดสอบเล็กน้อยของ MS แต่ตอนนี้ฉันกำลังใช้ NUnit อยู่ ปัญหาเกี่ยวกับ MS โดยทั่วไป (สำหรับฉัน)

• แชร์ไฟล์ "ทดสอบ" (ไม่มีจุดหมาย) ที่ต้องดูแลรักษา
• รายการทดสอบทำให้เกิดข้อขัดแย้งกับผู้พัฒนา / VCS หลายคน
• UI แบบรวมที่แย่ - การตั้งค่าที่สับสน, การเลือกทดสอบที่น่าเบื่อ
• ไม่มีนักวิ่งภายนอกที่ดี

Caveats - ถ้าฉันทดสอบไซต์ aspx ฉันจะใช้ MS อย่างแน่นอน - ถ้าฉันพัฒนาโซโล MS ก็น่าจะดี - ถ้าฉันมีทักษะ จำกัด และไม่สามารถกำหนดค่า NUnit ได้ :)

ฉันพบว่ามันง่ายกว่ามากที่จะเขียนการทดสอบของฉันและดับ NUnitGUI หรือปลายด้านหน้าอีกอันหนึ่ง (testDriven ไกลเกินกว่าไกลเกินไป) การตั้งค่าการดีบักด้วยเวอร์ชัน commandline นั้นค่อนข้างง่าย