คุณควรเขียนโค้ดของคุณในทุกการทดสอบทุกหน่วยหรือไม่

บทเรียน / ตัวอย่างการทดสอบหน่วยการเรียนรู้ส่วนใหญ่มักจะเกี่ยวข้องกับการกำหนดข้อมูลที่จะทดสอบสำหรับการทดสอบแต่ละครั้ง ฉันเดาว่านี่เป็นส่วนหนึ่งของทฤษฎี "ทุกสิ่งที่ควรทดสอบในการแยก"

อย่างไรก็ตามฉันพบว่าเมื่อต้องรับมือกับแอพพลิเคชั่นมัลติเทียร์ที่มีDIจำนวนมากรหัสที่จำเป็นสำหรับการตั้งค่าการทดสอบแต่ละครั้งจะยืดออกมาก แต่ฉันได้สร้างคลาส testbase จำนวนหนึ่งซึ่งตอนนี้ฉันสามารถสืบทอดซึ่งมีนั่งร้านทดสอบจำนวนมากที่สร้างไว้ล่วงหน้า

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

เป็นวิธีปฏิบัติที่ยอมรับได้หรือไม่หากไม่ใช่ทั้งหมดดังนั้นข้อมูลทดสอบส่วนใหญ่ในการทดสอบหน่วยทั้งหมดหรือไม่

ปรับปรุง

จากความคิดเห็นด้านล่างจะรู้สึกว่าฉันทำการรวมมากกว่าการทดสอบหน่วย

โครงการปัจจุบันของฉันคือ ASP.NET MVC โดยใช้หน่วยงานเหนือรหัส Framework ของ Entity ก่อนและ Moq สำหรับการทดสอบ ฉันเยาะเย้ย UoW และที่เก็บ แต่ฉันใช้คลาสตรรกะทางธุรกิจจริงและทดสอบการกระทำของคอนโทรลเลอร์ การทดสอบมักจะตรวจสอบว่า UoW ได้รับการมุ่งมั่นเช่น:

[TestClass]
public class SetupControllerTests : SetupControllerTestBase {
  [TestMethod]
  public void UserInvite_ExistingUser_DoesntInsertNewUser() {
    // Arrange
    var model = new Mandy.App.Models.Setup.UserInvite() {
      Email = userData.First().Email
    };

    // Act
    setupController.UserInvite(model);

    // Assert
    mockUserSet.Verify(m => m.Add(It.IsAny<UserProfile>()), Times.Never);
    mockUnitOfWork.Verify(m => m.Commit(), Times.Once);
  }
}

SetupControllerTestBaseเป็นอาคารจำลอง UoW และอินสแตนซ์userLogic

การทดสอบจำนวนมากจำเป็นต้องมีผู้ใช้หรือผลิตภัณฑ์ที่มีอยู่ในฐานข้อมูลดังนั้นฉันจึงเติมข้อมูลล่วงหน้าสิ่งที่ mock UoW ส่งกลับมาในตัวอย่างนี้userDataซึ่งเป็นเพียงการIList<User>บันทึกผู้ใช้เพียงครั้งเดียว

ท้ายที่สุดคุณต้องเขียนโค้ดให้น้อยที่สุดเพื่อให้ได้ผลลัพธ์มากที่สุด การมีรหัสเดียวกันจำนวนมากในการทดสอบหลายครั้งก) มีแนวโน้มที่จะส่งผลให้มีการคัดลอกและวางรหัส b) หมายความว่าหากวิธีการเปลี่ยนลายเซ็นคุณสามารถจบลงด้วยการแก้ไขการทดสอบที่เสียหายจำนวนมาก

ฉันใช้วิธีการมีคลาส TestHelper มาตรฐานที่ให้ฉันมีชนิดข้อมูลจำนวนมากที่ฉันใช้เป็นประจำดังนั้นฉันสามารถสร้างชุดเอนทิตีมาตรฐานหรือคลาสDTOสำหรับการทดสอบของฉันเพื่อค้นหาและรู้ว่าสิ่งที่ฉันจะได้รับในแต่ละครั้ง ดังนั้นฉันสามารถโทรหาTestHelper.GetFooRange( 0, 100 )ช่วงของวัตถุ 100 ฟูด้วยชุดคลาส / ฟิลด์ที่ขึ้นต่อกันทั้งหมด

โดยเฉพาะอย่างยิ่งที่มีความสัมพันธ์ที่ซับซ้อนที่กำหนดค่าในระบบประเภท ORM ซึ่งจำเป็นต้องมีเพื่อให้สิ่งต่าง ๆ ทำงานได้อย่างถูกต้อง แต่ไม่จำเป็นต้องมีความสำคัญสำหรับการทดสอบนี้ซึ่งสามารถประหยัดเวลาได้มาก

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

มีบางสิ่งที่ต้องระวังแม้ว่าในการทดสอบหน่วย:

• ตรวจสอบให้แน่ใจ mocks ของคุณมี mocks คลาสที่ดำเนินการกับคลาสที่ทดสอบจะต้องเป็นวัตถุจำลองหากคุณทำการทดสอบหน่วย คลาสประเภท DTO / เอนทิตีของคุณอาจเป็นของจริง แต่ถ้าคลาสดำเนินการดำเนินการคุณต้องเยาะเย้ยพวกเขา - ไม่เช่นนั้นเมื่อการเปลี่ยนแปลงรหัสสนับสนุนและการทดสอบของคุณเริ่มต้นล้มเหลวคุณต้องค้นหาอีกนานกว่านั้น ทำให้เกิดปัญหาจริง
• ให้แน่ใจว่าคุณกำลังทดสอบชั้นเรียนของคุณ บางครั้งหากมองผ่านชุดการทดสอบหน่วยจะเห็นได้ชัดว่าครึ่งหนึ่งของการทดสอบกำลังทดสอบกรอบการเยาะเย้ยมากกว่ารหัสจริงที่ควรทดสอบ
• อย่านำวัตถุจำลอง / วัตถุที่สนับสนุนมาใช้ใหม่นี่เป็นเรื่องใหญ่ - เมื่อใครคนหนึ่งเริ่มพยายามฉลาดด้วยการทดสอบหน่วยสนับสนุนรหัสมันเป็นเรื่องง่ายมากที่จะสร้างวัตถุที่ยังคงอยู่ระหว่างการทดสอบซึ่งอาจมีผลกระทบที่คาดเดาไม่ได้ ตัวอย่างเช่นเมื่อวานฉันมีการทดสอบที่ผ่านเมื่อทำงานด้วยตัวเองผ่านเมื่อการทดสอบทั้งหมดในชั้นเรียนถูกเรียกใช้ แต่ล้มเหลวเมื่อชุดทดสอบทั้งหมดถูกเรียกใช้ มันกลับกลายเป็นว่ามีวัตถุคงที่ลับ ๆ ล่อๆในผู้ช่วยทดสอบที่เมื่อฉันสร้างมันขึ้นมาแน่นอนจะไม่ทำให้เกิดปัญหาแน่นอน เพียงจำไว้ว่า: ในช่วงเริ่มต้นของการทดสอบทุกอย่างจะถูกสร้างขึ้นในตอนท้ายของการทดสอบทุกอย่างจะถูกทำลาย

อะไรก็ตามที่ทำให้การทดสอบของคุณอ่านง่ายขึ้น

ตามกฎทั่วไปของหัวแม่มือ:

หากข้อมูลเป็นส่วนหนึ่งของการทดสอบ (เช่นไม่ควรพิมพ์แถวที่มีสถานะเป็น 7) จากนั้นให้โค้ดในการทดสอบเพื่อให้ชัดเจนว่าผู้เขียนตั้งใจจะเกิดอะไรขึ้น

หากข้อมูลเป็นเพียงการเติมเพื่อให้แน่ใจว่ามีบางสิ่งบางอย่างที่จะทำงานร่วมกับ (เช่นไม่ควรทำเครื่องหมายบันทึกว่าสมบูรณ์ถ้าบริการการประมวลผลพ่นข้อยกเว้น) แล้วโดยวิธีการทั้งหมดมีวิธีการ BuildDummyData หรือชั้นทดสอบที่เก็บข้อมูลที่ไม่เกี่ยวข้องออกจากการทดสอบ .

แต่ทราบว่าฉันกำลังดิ้นรนที่จะคิดว่าเป็นตัวอย่างที่ดีของหลัง หากคุณมีหลายสิ่งเหล่านี้ในการติดตั้งหน่วยทดสอบคุณอาจมีปัญหาแตกต่างกันในการแก้ปัญหา ... บางทีวิธีการทดสอบนั้นซับซ้อนเกินไป

วิธีการทดสอบที่แตกต่างกัน

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

หากการทดสอบหน่วยของคุณดีคุณไม่จำเป็นต้องทำการทดสอบซ้ำทุกรายละเอียดเมื่อทำการทดสอบการรวม

ข้อกำหนดที่เราใช้นั้นขึ้นอยู่กับแพลตฟอร์มบิต แต่คุณสามารถค้นหาได้ในเกือบทุกแพลตฟอร์มทดสอบ / พัฒนา:

• การแข่งขัน: http://book.cakephp.org/2.0/en/development/testing.html#fixtures
• จำลอง: http://book.cakephp.org/2.0/th/development/testing.html#mocking-model-methods

ตัวอย่างการใช้งาน

ขึ้นอยู่กับเทคโนโลยีที่คุณใช้ชื่ออาจแตกต่างกัน แต่ฉันจะใช้สิ่งนี้เป็นตัวอย่าง:

หากคุณมีแอพพลิเคชั่น CRUD อย่างง่ายพร้อม Product Model, ProductsController และมุมมองดัชนีที่สร้างตาราง HTML พร้อมผลิตภัณฑ์:

ผลลัพธ์สุดท้ายของแอปพลิเคชันจะแสดงตาราง HTML พร้อมรายการผลิตภัณฑ์ทั้งหมดที่ใช้งานอยู่

การทดสอบหน่วย

แบบ

แบบจำลองที่คุณสามารถทดสอบได้ค่อนข้างง่าย มีวิธีการต่าง ๆ สำหรับมัน; เราใช้การแข่งขัน ฉันคิดว่านั่นคือสิ่งที่คุณเรียกว่า "ชุดข้อมูลปลอม" ดังนั้นก่อนการทดสอบแต่ละครั้งเราจะสร้างตารางและใส่ข้อมูลต้นฉบับ แพลตฟอร์มส่วนใหญ่มีวิธีการนี้ ตัวอย่างเช่นในคลาสทดสอบของคุณเมธอด setUp () ซึ่งรันก่อนการทดสอบแต่ละครั้ง

จากนั้นเราทำการทดสอบของเราตัวอย่างเช่น: testGetAllActive products

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

ในโลกแห่งความจริงคุณไม่สามารถปฏิบัติตามเสมอ 100% ความรับผิดชอบเดียว หากคุณต้องการทำสิ่งนี้ให้ดียิ่งขึ้นคุณสามารถใช้แหล่งข้อมูลที่คุณจำลอง สำหรับเรา (เราใช้ ORM) ที่ให้ความรู้สึกเหมือนทดสอบเทคโนโลยีที่มีอยู่แล้ว การทดสอบมีความซับซ้อนมากขึ้นและการทดสอบก็ไม่ได้ทดสอบจริง ๆ ดังนั้นเราจึงทำเช่นนี้

ข้อมูลที่เข้ารหัสแบบฮาร์ดจะถูกจัดเก็บแยกต่างหากในส่วนควบ ดังนั้นฟิกซ์เจอร์ก็เหมือนไฟล์ SQL ที่มีคำสั่งสร้างตารางและแทรกสำหรับบันทึกที่เราใช้ เราทำให้พวกเขามีขนาดเล็กเว้นแต่จะมีความต้องการที่แท้จริงในการทดสอบกับบันทึกจำนวนมาก

class ProductModel {
  public function getAllActive() {
    return $this->find('all', array('conditions' => array('active' => 1)));
  }
}

ตัวควบคุม

คอนโทรลเลอร์ต้องการงานมากกว่านี้เพราะเราไม่ต้องการทดสอบโมเดลด้วย ดังนั้นสิ่งที่เราทำคือเลียนแบบโมเดล นั่นหมายถึง: เราทดสอบ: index () วิธีการที่ควรกลับรายการของบันทึก

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

function testProductIndexLoggedIn() {
  $this->setLoggedIn();
  $this->ProductsController->mock('ProductModel', 'index', function(return array(your records) ));
  $result=$this->ProductsController->index();
  $this->assertEquals(2, count($result['products']));
}

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

ดังนั้นตัวควบคุมต้องการการเยาะเย้ยหนึ่งครั้งตามปกติและข้อมูล hardcoded ขนาดเล็ก สำหรับระบบเข้าสู่ระบบอาจเป็นอีกระบบหนึ่ง ในการทดสอบของเราเรามีวิธีการช่วยเหลือสำหรับมัน: setLoggedIn () ทำให้ง่ายต่อการทดสอบด้วยการเข้าสู่ระบบหรือไม่มีการเข้าสู่ระบบ

class ProductsController {
  public function index() {
    if($this->loggedIn()) {
      $this->set('products', $this->ProductModel->getAllActive());
    }
  }
}

เข้าชม

การทดสอบการดูเป็นเรื่องยาก ก่อนอื่นเราแยกตรรกะออกซึ่งทำซ้ำ เราวางไว้ในผู้ช่วยเหลือและทดสอบคลาสเหล่านั้นอย่างเข้มงวด เราคาดหวังผลลัพธ์เดียวกันเสมอ ตัวอย่างเช่น generateHtmlTableFromArray ()

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

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

echo $this->tableHelper->generateHtmlTableFromArray($products);

การทดสอบบูรณาการ

ขึ้นอยู่กับแพลตฟอร์มของคุณที่นี่คุณสามารถทำงานร่วมกับเรื่องราวของผู้ใช้ ฯลฯ มันอาจจะเป็น webbased เช่นSeleniumหรือโซลูชันอื่น ๆ ที่เทียบเท่ากัน

โดยทั่วไปเราเพิ่งโหลดฐานข้อมูลพร้อมติดตั้งและยืนยันว่าข้อมูลใดควรพร้อมใช้งาน สำหรับการทดสอบแบบบูรณาการโดยทั่วไปเราใช้ข้อกำหนดระดับโลกมาก ดังนั้น: ตั้งค่าผลิตภัณฑ์ให้เปิดใช้งานและตรวจสอบว่าผลิตภัณฑ์นั้นพร้อมใช้งานหรือไม่

เราไม่ได้ทดสอบทุกอย่างอีกเช่นว่ามีฟิลด์ที่เหมาะสมหรือไม่ เราทดสอบข้อกำหนดที่ใหญ่กว่าที่นี่ เนื่องจากเราไม่ต้องการทำซ้ำการทดสอบของเราจากคอนโทรลเลอร์หรือมุมมอง หากมีบางอย่างที่เป็นกุญแจ / ส่วนหลักของแอปพลิเคชันของคุณหรือเพื่อเหตุผลด้านความปลอดภัย (ตรวจสอบรหัสผ่านไม่พร้อมใช้งาน) เราจะเพิ่มสิ่งเหล่านั้นเพื่อให้แน่ใจว่าถูกต้อง

ข้อมูลที่เข้ารหัสยากถูกเก็บไว้ในส่วนควบ

function testIntegrationProductIndexLoggedIn() {
  $this->setLoggedIn();
  $result=$this->request('products/index');

  $expected='<table';
  $this->assertContains($expected, $result);

  // Some content from the fixture record
  $expected='<td>Product 1 name</td>';
  $this->assertContains($expected, $result);
}

หากคุณกำลังเขียนการทดสอบที่เกี่ยวข้องกับ DI และสายไฟมากถึงการใช้แหล่งข้อมูล "ของจริง" คุณอาจออกจากพื้นที่ของการทดสอบหน่วยธรรมดาและป้อนโดเมนของการทดสอบการรวม

สำหรับการทดสอบการรวมเข้าด้วยกันฉันไม่คิดว่าจะมีตรรกะการตั้งค่าข้อมูลทั่วไป เป้าหมายหลักของการทดสอบดังกล่าวคือการพิสูจน์ว่าทุกอย่างได้รับการกำหนดค่าอย่างถูกต้อง สิ่งนี้ค่อนข้างเป็นอิสระจากข้อมูลที่เป็นรูปธรรมที่ส่งผ่านระบบของคุณ

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

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

ฉันคิดว่ามันเป็นเรื่องธรรมดาที่จะใช้รหัสยากสำหรับการทดสอบของคุณ

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

ข้อมูลการทดสอบที่กำหนดไว้ล่วงหน้ายังช่วยให้คุณสามารถสร้างชุดข้อมูลที่ครอบคลุมช่วงสถานการณ์ที่กว้างและเป็นที่รู้จัก

ที่กล่าวว่าฉันคิดว่ายังมีค่าในการมีข้อมูลสุ่มในการทดสอบของคุณ