ข้อมูลจำเพาะและ ScalaTest เป็นเครื่องมือที่ดีสำหรับผู้ใช้ที่พึงพอใจ แต่แตกต่างกันในหลายวิธี คุณอาจต้องการเลือกเครื่องมือทดสอบหลักใน Scala แต่ไม่จำเป็นต้องยอมแพ้เพราะคุณสามารถใช้ทั้งสองอย่างได้ ตัวอย่างเช่นหากคุณชอบFeatureSpecไวยากรณ์ของ ScalaTest และไวยากรณ์ของ Mockito คุณสามารถใส่ไฟล์ jar ทั้งสองไฟล์ใน classpath ของคุณและใช้ทั้งสองอย่างพร้อมกันได้ ที่นี่ฉันจะพยายามจับความแตกต่างหลักปรัชญาการออกแบบที่ฉันสังเกตเห็นระหว่างข้อมูลจำเพาะและ ScalaTest
อาจเป็นความแตกต่างทางปรัชญาที่สำคัญระหว่างเครื่องมือคือข้อมูลจำเพาะได้รับการออกแบบมาสำหรับ Behavior-Driven Development (BDD) ในขณะที่ ScalaTest มีความกว้างมากกว่า ScalaTest มีลักษณะที่คุณสามารถผสมเข้าด้วยกันเพื่อให้ได้พฤติกรรมที่คุณต้องการในชั้นเรียนทดสอบของคุณรวมถึง BDD และคุณยังสามารถกำหนดพฤติกรรมของคุณเองได้อย่างง่ายดายหากคุณต้องการสิ่งที่แตกต่างออกไป
สนับสนุน ScalaTest BDD ผ่านSpec, FeatureSpec, WordSpec, FlatSpecและGivenWhenThenลักษณะและยังมีลักษณะที่คุณสามารถผสมในการได้รับการจับคู่ที่ดีไวยากรณ์ ถ้าคุณชอบ "ควร" คุณผสมใน ShouldMatchers ถ้าคุณชอบ "ต้อง" MustMatchersคุณผสมใน แต่ถ้าคุณชอบ BDD แต่ไม่ชอบไวยากรณ์ของตัวจับคู่คุณสามารถใช้ลักษณะ Spec ของ ScalaTest ได้โดยไม่ต้องผสมในลักษณะ matchers Specs มีคลาส Specification ที่คุณขยายและคุณต้องใช้คำว่า "must" ในนิพจน์ตัวจับคู่ของคุณ ความแตกต่างทางปรัชญาที่เห็นได้ชัดคือ ScalaTest ให้ทางเลือกมากมายแก่คุณ เพื่อให้ง่ายต่อการสำรวจพื้นที่นี้ฉันให้แผนผังการตัดสินใจที่นี่:
http://www.scalatest.org/quick_start
ไวยากรณ์การจับคู่ยังแตกต่างกันระหว่าง ScalaTest และข้อกำหนด ใน ScalaTest ฉันพยายามดูว่าฉันจะไปได้ไกลแค่ไหนด้วยสัญกรณ์ตัวดำเนินการและลงเอยด้วยนิพจน์จับคู่ที่อ่านคล้ายประโยคภาษาอังกฤษมากโดยเว้นวรรคระหว่างคำ ไวยากรณ์ตัวจับคู่ข้อมูลจำเพาะเรียกใช้คำร่วมกันมากขึ้นด้วยตัวพิมพ์ใหญ่อูฐ
ข้อมูลจำเพาะมีผู้จับคู่มากกว่า ScalaTest และฉันคิดว่าสะท้อนให้เห็นถึงความแตกต่างในทัศนคติการออกแบบ จริงๆแล้วฉันอาจจะตัด 2/3 ของไวยากรณ์ตัวจับคู่ที่ฉันสร้างและพิจารณาสำหรับการเปิดตัว ฉันจะเพิ่มตัวจับคู่เพิ่มเติมในรุ่นต่อ ๆ ไป แต่อยากให้แน่ใจว่าฉันรู้ว่าผู้ใช้ต้องการบางอย่างจริงๆก่อนที่จะเพิ่ม อย่างไรก็ตามตัวจับคู่ของ ScalaTest มีไวยากรณ์ตัวจับคู่คุณสมบัติแบบไดนามิกจะใช้ค่าหย่อนบางส่วน ตัวอย่างเช่นใน Specs คุณสามารถเขียนบนjava.io.File:
file must beDirectory
สิ่งนี้จะเรียกisDirectoryและตรวจสอบให้แน่ใจว่าเป็นจริง ScalaTest ไม่มีตัวจับคู่พิเศษสำหรับjava.io.Filesปัจจุบัน แต่ใน ScalaTest คุณสามารถใช้การตรวจสอบแบบไดนามิกดังนี้:
file must be a ('directory)
เวลาที่คุณผ่านสัญลักษณ์หลังจากbeนั้นก็จะใช้สะท้อนที่จะมองหา (ในกรณีนี้) วิธีการหรือสาขาที่ชื่อหรือวิธีการตั้งชื่อdirectory isDirectoryนอกจากนี้ยังมีวิธีสร้างแบบคงที่โดยการกำหนด a BePropertyMatcher(ซึ่งโดยปกติต้องใช้โค้ดเพียง 2 หรือ 3 บรรทัด) โดยพื้นฐานแล้วใน ScalaTest ฉันพยายามให้ฟังก์ชันการทำงานมากขึ้นโดยใช้ API น้อยลง
ความแตกต่างของทัศนคติในการออกแบบทั่วไปอีกประการหนึ่งระหว่างข้อกำหนดและ ScalaTest เกี่ยวข้องกับการแปลงโดยนัย โดยค่าเริ่มต้นคุณจะได้รับการแปลงโดยนัยเพียงครั้งเดียวเมื่อคุณใช้ ScalaTest ซึ่งเป็นสิ่งที่ทำให้ตัว===ดำเนินการทุกอย่าง (หากต้องการคุณสามารถ "ปิด" การแปลงโดยนัยนี้ได้ด้วยโค้ดบรรทัดเดียวเหตุผลเดียวที่คุณต้องทำคือถ้าคุณพยายามทดสอบบางอย่างที่มีตัว===ดำเนินการของตัวเองและคุณได้รับข้อขัดแย้ง ) ScalaTest กำหนด Conversion โดยนัยอื่น ๆ อีกมากมาย แต่หากต้องการใช้คุณจะต้อง "เชิญ" เข้ามาในโค้ดของคุณอย่างชัดเจนโดยการผสมในลักษณะหรือการนำเข้า เมื่อคุณขยายชั้นเรียนSpecificationในรายละเอียดฉันคิดว่าคุณจะได้รับการแปลงโดยนัยเป็นจำนวนมากโดยค่าเริ่มต้น ฉันไม่แน่ใจว่าจะมีความสำคัญมากแค่ไหนในทางปฏิบัติ แต่ฉันคิดว่าผู้คนจะต้องการทดสอบโค้ดที่ใช้ความหมายของตัวเองและบางครั้งอาจมีความขัดแย้งระหว่างนัยของกรอบการทดสอบและรหัสการผลิต เมื่อเป็นเช่นนั้นฉันคิดว่าการแก้ไขปัญหาใน ScalaTest อาจง่ายกว่าข้อกำหนด
ความแตกต่างในทัศนคติการออกแบบที่ฉันสังเกตเห็นคือความสะดวกสบายกับผู้ปฏิบัติงาน เป้าหมายอย่างหนึ่งที่ฉันมีคือโปรแกรมเมอร์ที่ดูรหัสทดสอบของคนอื่นที่ใช้ ScalaTest จะสามารถเดาความหมายได้โดยไม่ต้องค้นหาอะไรในเอกสาร ScalaTest ฉันต้องการให้รหัสไคลเอนต์ ScalaTest ลดลงอย่างชัดเจน วิธีหนึ่งที่แสดงให้เห็นถึงเป้าหมายคือ ScalaTest มีความระมัดระวังเกี่ยวกับตัวดำเนินการ ฉันกำหนดเพียงห้าตัวดำเนินการใน ScalaTest:
===ซึ่งหมายความว่าเท่ากับ>ซึ่งหมายความว่ามากกว่า<, น้อยกว่า>=มากกว่าหรือเท่ากับ<=น้อยกว่าหรือเท่ากับ
แค่นั้นแหละ. ดังนั้นสิ่งเหล่านี้ดูเหมือนความหมาย หากคุณเห็นในรหัสของคนอื่น:
result should be <= 7
ความหวังของฉันคือคุณไม่จำเป็นต้องเรียกใช้เอกสาร API เพื่อเดาว่ามัน<=หมายถึงอะไร ในทางตรงกันข้ามข้อมูลจำเพาะจะเป็นอิสระกว่ามากสำหรับตัวดำเนินการ ไม่มีอะไรผิดปกติ แต่มันเป็นความแตกต่าง ผู้ประกอบการสามารถให้รหัสอื่น ๆ กระชับ แต่ถ่วงดุลอำนาจคือการที่คุณอาจต้องใช้เอกสารเมื่อคุณพบสิ่งที่ต้องการ ->-, >>, |, |>, !หรือ^^^(ซึ่งทุกคนมีความหมายพิเศษในรายละเอียด) ในรหัสการทดสอบเพื่อนร่วมงานของคุณ
ความแตกต่างทางปรัชญาอีกประการหนึ่งคือฉันพยายามทำให้ง่ายขึ้นเล็กน้อยใน ScalaTest เพื่อใช้รูปแบบการทำงานเมื่อคุณต้องการแชร์ฟิกซ์เจอร์ในขณะที่ Specs โดยค่าเริ่มต้นจะยังคงประเพณีของsetUpและtearDownแนวทางที่ได้รับความนิยมโดย JUnit ซึ่งคุณกำหนด vars ใหม่ ก่อนการทดสอบแต่ละครั้ง อย่างไรก็ตามหากคุณต้องการทดสอบวิธีนั้นก็ทำได้ง่ายมากใน ScalaTest คุณเพียงแค่ต้องผสมในBeforeAndAfterลักษณะ
สำหรับข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับ ScalaTest คุณสามารถรับชมการนำเสนอ "Get Higher with ScalaTest" ที่ฉันมอบให้ในการประชุม Devoxx ปี 2009 ได้ที่นี่:
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about