ฉันใช้วิธีแรก แต่แตกต่างกันเล็กน้อยที่ช่วยแก้ไขปัญหาที่คุณกล่าวถึง
ทุกอย่างที่จำเป็นในการเรียกใช้การทดสอบสำหรับ DAO อยู่ในการควบคุมของแหล่งที่มา มันมีสคีมาและสคริปต์เพื่อสร้างฐานข้อมูล (นักเทียบท่าเป็นสิ่งที่ดีสำหรับเรื่องนี้) หากสามารถใช้ฐานข้อมูลแบบฝังได้ - ฉันใช้เพื่อความเร็ว
ความแตกต่างที่สำคัญกับวิธีการอธิบายอื่น ๆ คือข้อมูลที่จำเป็นสำหรับการทดสอบไม่ได้โหลดจากสคริปต์ SQL หรือไฟล์ XML ทุกอย่าง (ยกเว้นข้อมูลพจนานุกรมบางส่วนที่มีประสิทธิภาพคงที่) สร้างขึ้นโดยแอปพลิเคชันโดยใช้ฟังก์ชัน / คลาสยูทิลิตี้
วัตถุประสงค์หลักคือเพื่อให้ข้อมูลที่ใช้โดยการทดสอบ
- ใกล้กับการทดสอบมาก
- ชัดเจน (การใช้ไฟล์ SQL สำหรับข้อมูลทำให้เกิดปัญหามากในการดูว่าส่วนใดของข้อมูลที่ใช้ในการทดสอบแบบใด)
- แยกการทดสอบออกจากการเปลี่ยนแปลงที่ไม่เกี่ยวข้อง
โดยพื้นฐานแล้วหมายความว่ายูทิลิตี้เหล่านี้อนุญาตให้ระบุสิ่งที่จำเป็นสำหรับการทดสอบในการทดสอบตัวเองและละเว้นสิ่งที่ไม่เกี่ยวข้อง
เพื่อให้ความคิดของสิ่งที่มันหมายในทางปฏิบัติบางพิจารณาการทดสอบสำหรับ DAO บางส่วนที่ทำงานร่วมกับCommentเพื่อPosts Authorsเขียนโดย เพื่อทดสอบการทำงานของ CRUD สำหรับ DAO เช่นนั้นข้อมูลบางอย่างควรถูกสร้างขึ้นในฐานข้อมูล การทดสอบจะมีลักษณะดังนี้:
@Test
public void savedCommentCanBeRead() {
// Builder is needed to declaratively specify the entity with all attributes relevant
// for this specific test
// Missing attributes are generated with reasonable values
// factory's responsibility is to create entity (and all entities required by it
// in our example Author) in the DB
Post post = factory.create(PostBuilder.post());
Comment comment = CommentBuilder.comment().forPost(post).build();
sut.save(comment);
Comment savedComment = sut.get(comment.getId());
// this checks fields that are directly stored
assertThat(saveComment, fieldwiseEqualTo(comment));
// if there are some fields that are generated during save check them separately
assertThat(saveComment.getGeneratedField(), equalTo(expectedValue));
}
สิ่งนี้มีข้อดีกว่าสคริปต์ SQL หรือไฟล์ XML ที่มีข้อมูลทดสอบ:
- การบำรุงรักษารหัสนั้นง่ายกว่ามาก (การเพิ่มคอลัมน์บังคับเช่นในบางเอนทิตีที่อ้างอิงในการทดสอบหลายอย่างเช่นผู้แต่งไม่จำเป็นต้องเปลี่ยนไฟล์ / บันทึกจำนวนมาก แต่เพียงการเปลี่ยนแปลงในตัวสร้างและ / หรือโรงงาน)
- ข้อมูลที่ต้องการโดยการทดสอบที่เฉพาะเจาะจงอธิบายไว้ในการทดสอบตัวเองและไม่ได้อยู่ในไฟล์อื่น ๆ ความใกล้เคียงนี้มีความสำคัญอย่างยิ่งสำหรับความเข้าใจในการทดสอบ
ย้อนกลับ vs กระทำ
ฉันคิดว่าสะดวกกว่าที่จะทำการทดสอบเมื่อมีการดำเนินการ ประการแรกเอฟเฟกต์บางอย่าง (ตัวอย่างDEFERRED CONSTRAINTS) ไม่สามารถตรวจสอบได้หากการกระทำไม่เคยเกิดขึ้น ประการที่สองเมื่อการทดสอบล้มเหลวสามารถตรวจสอบข้อมูลในฐานข้อมูลได้เนื่องจากไม่ได้ทำการย้อนกลับโดยการย้อนกลับ
ด้วยสาเหตุนี้มีข้อเสียที่การทดสอบอาจสร้างข้อมูลที่เสียหายและสิ่งนี้จะนำไปสู่ความล้มเหลวในการทดสอบอื่น ๆ เพื่อจัดการกับเรื่องนี้ฉันพยายามที่จะแยกการทดสอบ ในตัวอย่างข้างต้นทุกการทดสอบอาจสร้างใหม่Authorและหน่วยงานอื่น ๆ ทั้งหมดจะถูกสร้างขึ้นที่เกี่ยวข้องกับมันเพื่อให้การชนเป็นเรื่องยาก เพื่อจัดการกับค่าคงที่ที่เหลือซึ่งอาจแตกหัก แต่ไม่สามารถแสดงเป็นข้อ จำกัด ระดับ DB ฉันใช้การตรวจสอบแบบเป็นโปรแกรมบางอย่างสำหรับเงื่อนไขที่ผิดพลาดที่อาจเรียกใช้หลังจากการทดสอบทุกครั้ง (และพวกเขาจะทำงานใน CI เหตุผล)