แนะนำ tspec ครับ, ิbdd framework ที่สนับสนุนภาษาไทย Options

[cblue]

หลังจากลองผิดลองถูกมาพักใหญ่กับ BDD (และ wiki) และการใช้งานภาษาไทย ในที่สุดก็ตกผลึกออกมาเป็น framework ที่ตั้งใจจะให้ใช้ได้สำหรับทวนสอบข้อกำหนด requirements ของผู้ใช้และให้สามารถเข้าใจได้ตรงกันมากที่สุดเท่าที่จะทำได้ นั่นคือมีข้อกำหนดภาษาไทยที่ทำงานได้จริง และใช้งานได้กับทั้ง Java และ Groovy แบบไม่สะดุด

เลยออกมาเป็นอย่างที่เห็นครับ ต่อไปนี้ครับ

CODE

package org.tspec.hangman

import org.tspec.hangman.Hangman

เรื่อง 'คนแขวนคอ'

อธิบาย 'การตั้งค่าที่เหมาะสมสำหรับเริ่มต้น',{
กำหนดให้ 'มีวัตถุคนแขวนคอ', {
hangman = new Hangman()
}
เมื่อ 'ตั้งค่าคำไว้เป็นค่า hello',{
hangman.word = 'hello'
}
แล้ว 'ตัววัตถุควรมีการตั้งค่าที่เหมาะสม',{
hangman.word.should == 'hello'
hangman.wrongs.should == 0
hangman.maxGuess.should == 12
hangman.unrevealedWord.should == ['_', '_', '_', '_', '_']
hangman.finished.should == false
}
}

โค้ดด้านบนเป็นตัวอย่างสคริปต์ภาษาไทย + Groovy (1 สถานการณ์) ที่เครื่องมือชื่อ tspec สามารถนำไปรันได้
และจะรายงานออกมาเป็นลักษณะคล้าย ๆ ต่อไปนี้ (ด้านล่างผมรันสคริปต์เต็ม ซึ่งมี 4 สถานการณ์)

CODE

เรื่อง คนแขวนคอ
การตั้งค่าที่เหมาะสมสำหรับเริ่มต้น
กำหนดให้ มีวัตถุคนแขวนคอ และเมื่อตั้งค่าคำไว้เป็นค่า hello
แล้วตัววัตถุควรมีการตั้งค่าที่เหมาะสม / ผ่าน
จบ สถานการณ์
การตั้งค่าจำนวนครั้งที่เล่นผิดให้เป็น 0 ถ้าผู้เล่นต้องการเล่นเกมใหม่
กำหนดให้ มีวัตถุคนแขวนคอ เพื่อเล่นคำว่า hello และเมื่อผู้เล่นเล่นเกมไปแล้วด้วยการทาย a และสั่งให้เริ่มเกมใหม่
แล้วจำนวนครั้งของการเล่นผิดควรเป็น 0 / ผ่าน
จบ สถานการณ์
การเดาผิดหมด
กำหนดให้ มีวัตถุคนแขวนคอ เพื่อเล่นคำว่า hello และเมื่อเดาครั้งแรกผิด
แล้วจำนวนการผิดควรเป็น 1 / ผ่าน
และเมื่อเดาครั้งที่ 2 ผิด จำนวนการผิดควรเป็น 2 / ผ่าน
และเมื่อเดาผิดครบ 12 ครั้ง จำนวนการผิดควรเป็น 12 / ผ่าน
แล้วหากเดาผิดอีกครั้ง ควรขว้างข้อผิดพลาดจำนวนครั้งที่เดาเกิน / ผ่าน
จบ สถานการณ์
การเดาถูกหมด
กำหนดให้ มีวัตถุคนแขวนคอ เพื่อเล่นคำว่า hello และเมื่อเดาครั้งแรกถูก
แล้วจำนวนครั้งที่ผิดควรเป็น 0 / ผ่าน
และคำที่ซ่อนอยู่ควรเป็น h และช่องว่าง 4 ตัว / ผ่าน
และเมื่อทายด้วย e / ผ่าน
แล้วจำนวนครั้งที่ผิดควรจะยังเป็น 0 อยู่ / ผ่าน
และคำที่ซ่อนอยู่ควรเป็น he และช่องว่าง 3 ตัว / ผ่าน
และเมื่อทายด้วย l / ผ่าน
แล้วจำนวนครั้งที่ผิดควรจะยังเป็น 0 อยู่ / ผ่าน
และคำที่ซ่อนอยู่ควรเป็น hell และช่องว่าง 1 ตัว / ผ่าน
และเมื่อทายด้วย o / ผ่าน
แล้วจำนวนครั้งที่ผิดควรจะยังเป็น 0 อยู่ / ผ่าน
และคำที่ซ่อนอยู่ควรเป็น hello และจบการเล่น / ผ่าน
จบ สถานการณ์
จำนวนสถานการณ์ทั้งหมด: 4 ผ่าน

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

ตอนนี้สามารถดูโค้ดทั้งหมดได้จาก
http://geogia.googlecode.com/svn/trunk/spec/new_src/

ตัวอย่างเต็มของ HangmanStory ดูได้จาก
http://geogia.googlecode.com/svn/trunk/spe...manStory.groovy

ต้นฉบับภาษา Ruby + อังกฤษ จากเวบของคุณข้าวโพดหวาน
http://www.thaidev.org/?p=55

[minimalist]

ยังไม่ได้เข้าไปอ่านตามลิงค์อย่างละเอียด แต่แนวโน้มน่าจะออกมาดีแน่ ๆ

ผมเพิ่งสอนเกี่ยวกับ requirements management ไปเมื่อสัปดาห์ที่ผ่านมา
งานนี้ของคุณ cblue น่าจะช่วยสนับสนุกกระบวนการ realization และ traceability ได้เป็นอย่างดีทีเีดียว
gap ระหว่าง system analyst และ programmer ก็จะลดลงมากยิ่งขึ้น
คนต้องชอบมากแน่ ๆ เพราะมัน 'agile' สุด ๆ และ 'เวิร์ก'
ขอสนับสนุนและเป็นกำลังใจให้พัฒนางานนี้ไปเรื่อย ๆ จนสุด ๆ นะครับ
หากมีโอกาสเหมาะสมจะช่วยแนะนำและเผยแพร่ให้ครับ จะได้ช่วย ๆ กันนำไปลองและต่อยอดมาก ๆ

เดี๋ยวไว้ผมพ้นช่วงงานยุ่ง ๆ แล้วจะเข้ามาลองด้วยเช่นกันครับ

ขอบคุณครับสำหรับสิ่งดี ๆ และการแบ่งปัน

[cblue]

ขอบคุณครับคุณ mininalist

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

[cblue]

อัพเดตครับ

ตอนนี้ลองใช้เป็นแบบ command line ผ่าน console พบว่าไม่ค่อยสะดวกเนื่องจากสาเหตุหลายประการ
เช่น การแสดงข้อความภาษาไทยใน console เป็นต้น
ผมคิดว่าการใ้ช้งานร่วมกับ IDE เช่น Eclipse น่าจะเหมาะสมกว่า เลยคิดว่าคงจะทำให้ออกมาเป็น plugin ง่าย ๆ ที่จะช่วยรัน story โดยตรงจาก Eclipse แบบ JUnit ครับ
แต่ผมยังไม่เคยลองทำ plugin แบบเป็นเรื่องเป็นราว เลยอาจจะใช้เวลาอีกสักพักในการแกะจากตัวอย่างอื่น

ท่านใดมีข้อเสนอแนะเพิ่มเติมก็จะยินดีมากครับ

[xcaleber]

ยินดีด้วยครับ

มีคำถามครับ เขียนใหม่ทั้งหมดเลยหรือเปล่าครับ หรือว่าข้างล่างเรียกใช้ easyb ครับ

[cblue]

ยินดีด้วยครับ

มีคำถามครับ เขียนใหม่ทั้งหมดเลยหรือเปล่าครับ หรือว่าข้างล่างเรียกใช้ easyb ครับ

เขียนขึ้นใหม่หมดครับผม

เหตุผลก็คือ ตอนแรกว่าจะ wrap โค้ดของ easyb แต่มันเยิ่นเย้อไปหน่อยแล้วก็ทำบางอย่างที่อยากได้ไม่ได้ เช่น ต้องเขียน

1.shouldBe 1 เพื่อทำ assertion

แต่ใน tspec ใช้เทคนิคของ ExpandoMetaclass (ความรู้จากการแกะ Grails) ทำให้เขียน

1.should == 1

ได้
๋
ความเห็นส่วนตัว เพราะดูจาก rspec แล้ว เขียนแบบ '.should ==' มันกระชับกว่า ทั่วไปกว่า และไม่ต้องให้คนใช้เรียนรู้ syntax อะไรเพิ่มเติ่มครับ

แล้วก็รับประกันครับว่าเร็วกว่า easyb เพราะหลาย ๆ จุดใช้การ implement Closure และเรียกใช้โดยตรงโดยไม่ผ่าน meta-layer ของ Groovy

จริงๆ แล้วมีเทคนิคแปลก ๆ อีกพอสมควรที่ใช้ในการสร้าง tspec แต่คิดว่าคงไม่น่าจะเอามาเป็นประเด็นในกระทู้นี้ครับ (แค่นี้ก็ออกทะเลไปเยอะแล้ว )

[xcaleber]

จริงๆ แล้วมีเทคนิคแปลก ๆ อีกพอสมควรที่ใช้ในการสร้าง tspec แต่คิดว่าคงไม่น่าจะเอามาเป็นประเด็นในกระทู้นี้ครับ (แค่นี้ก็ออกทะเลไปเยอะแล้ว )

ทำเป็น series เลยครับ :-)

[นายข้าวโพดหวาน]

น่าสนใจมากครับ tspec/gspec น่าจะเหมาะกว่า rspec ในแง่สามารถเขียนสเปกด้วยภาษาจาวาได้โดยตรง ในขณะที่ rspec ต้องเขียนสเปกด้วยรูบี้ ดังนั้นเอา tspec มาใช้กับจาวาจะมีประโยชน์ต่อคนจำนวนมากที่ใช้จาวา

แล้ว tspec สนับสนุน before(:all), before(:each), after(:all), after(:each) ด้วยหรือเปล่าครับ

[cblue]

น่าสนใจมากครับ tspec/gspec น่าจะเหมาะกว่า rspec ในแง่สามารถเขียนสเปกด้วยภาษาจาวาได้โดยตรง ในขณะที่ rspec ต้องเขียนสเปกด้วยรูบี้ ดังนั้นเอา tspec มาใช้กับจาวาจะมีประโยชน์ต่อคนจำนวนมากที่ใช้จาวา

หนึ่งในจุดประสงค์หลักครับ
แล้วก็ตัว test case 2 ตัวที่ใช้ทดสอบการเขียนคลาส (Hangman และ Stack) ก็เป็นจาวาทั้งคู่ครับ

แล้ว tspec สนับสนุน before(:all), before(:each), after(:all), after(:each) ด้วยหรือเปล่าครับ

ยังครับ การอิมพลีเม้นต์ไม่ยาก แต่ยังหาคำแปลเหมาะ ๆ ไม่ได้
ที่คิดไว้คือ

- ก่อน/หลัง ทุกกรณี
- ก่อน/หลัง แต่ละกรณี

แต่อ่านแล้วยังแปลก ๆ อยู่ครับ

[cblue]

จริงๆ แล้วมีเทคนิคแปลก ๆ อีกพอสมควรที่ใช้ในการสร้าง tspec แต่คิดว่าคงไม่น่าจะเอามาเป็นประเด็นในกระทู้นี้ครับ (แค่นี้ก็ออกทะเลไปเยอะแล้ว )

ทำเป็น series เลยครับ :-)

ไว้จะหาที่ลงครับ (บล็อกไทยเกรลส์ไม่ค่อยเหมาะ ถ้าทำจริงอาจจะต้องรบกวน thaidev.org ของนายข้าวโพดหวานแทน)

[minimalist]

ยินดีมาก ๆ ครับคุณ cblue หากผมพอจะช่วยอะไรได้บ้างก็ยินดี เต็มที่ครับ

อยากเพิ่มเติมว่าตอนนี้บ้านเราปัญหาที่วิกฤตจริง ๆ น่าจะเป็นเรื่อง requirements management และ testing มากกว่าสิ่งใดครับ
โดย requirements management หนักที่สุดครับ ใครหลายคนหลายฝ่ายอาจบอกว่าวิกฤตคือ process และ architecture แต่ในความคิดเห็นของผมคือไม่ว่า process จะดีหรือห่วย และ architecture จะเยี่ยมหรือแย่ ไม่ว่างานจะเล็กหรือใหญ่ ทีมจะเก่งหรือไม่เก่ง จะใช้เทคโนโลยีอะไร ภาษาอะไร ล้วนแล้วต้องทำ requirements และ testing ทั้งนั้น แต่การจัดการ requirements และ testing ในปัจจุบันมันเก่าและโบราณแล้วและมักทำกันผิด ๆ

เช่น testing คนส่วนใหญ่มักทำแค่ functional test เท่านั้น ซึ่งไม่ได้ test ในมิติอื่น ๆ กันสักเท่าไรเลย ยิ่งการนำหลักการ Test Driven Development เข้ามาใช้ ยิ่งเป็น 'new paradigm' ถึงขั้นเข้าไปกระทบวัฒนธรรมการทำงานและนิสัยการทำงานของคนกันเลยทีเดียว รวมถึงกระทบการบริหารจัดการด้วย ยิ่งทีมใหญ่ ๆ คนเยอะ ๆ ยิ่งยาก เพราะวิธีคิดมันเปลี่ยนไปเยอะมาก และยังมีอีกหลายเหตุผล

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

ปัญหาใหญ่ ๆ ที่มักเจอกันบ่อย ๆ คือคนมักไปทุ่มเทกับงานเอกสาร requirements เอาเป็นเอาตาย ผมจึงเล็งเห็นว่าสิ่งที่คุณ cblue กำลังทำอยู่น่าจะตอบโจทย์ได้เป็นอย่างดีในการสนับสนุนการจัดการหลาย ๆ ด้านในการจัดการ requirements

แนวทางการจัดการ requirements ที่เวิร์คที่สุดในโลกตอนนี้คือ Unified Approach วิจัยและพัฒนาโดย Rational (ตั้งแต่สมัยก่อนถูก acquire โดย IBM) เรียกได้ว่าเป็นการฉีก paradigm เดิม ๆ กระจุย และให้ภาพเป็นรูปธรรมและตอบสนองการทำงานจริงได้มาก

ส่วนสิ่งที่คุณ cblue กำลังทำอยู่ เรื่องข้อจำกัดของภาษาไทยผมว่าไม่มีปัญหาครับ เพราะภาษาไทยก็เป็นภาษาที่มีไวยกรณ์อยู่ ก็น่าจะสร้างเป็น patterns / rules ได้ เช่นน้ำหนักของความต้องการของคำว่า 'ต้อง', 'น่าจะ', 'อาจ', 'ควร', 'might', 'should', 'would', 'could', 'shall', 'won't', 'must' ฯลฯ ต่างก็มีน้ำหนักไม่เท่ากัน ก็ต้องไปดูเรื่องภาษา และหลักกฏหมายประกอบ (เพราะ requirements ที่สิ่งที่ทีม commit กับ stakeholder จึงส่งผลด้านกฏหมายด้วย)

เดี๋ยวอีก 2-3 วันผมขอลองเล่นแล้วจะมาพูดถึงต่อนะครับ

ทำไปเรื่อย ๆ นะครับ ผมเชียร์สุดใจขาดดิ้นเลย

ป.ล. ไอเดียที่คุณ cblue และ juacompe (SPL + AOP) กำลังทำ มักทำให้ผมขนลุกอยู่เรื่อย 555 เพราะมันเป็นการตอบโจทย์ได้ตรงจริง ๆ

[cblue]

ยินดีมาก ๆ ครับคุณ cblue หากผมพอจะช่วยอะไรได้บ้างก็ยินดี เต็มที่ครับ

ขอบคุณครับ

ส่วนสิ่งที่คุณ cblue กำลังทำอยู่ เรื่องข้อจำกัดของภาษาไทยผมว่าไม่มีปัญหาครับ เพราะภาษาไทยก็เป็นภาษาที่มีไวยกรณ์อยู่ ก็น่าจะสร้างเป็น patterns / rules ได้ เช่นน้ำหนักของความต้องการของคำว่า 'ต้อง', 'น่าจะ', 'อาจ', 'ควร', 'might', 'should', 'would', 'could', 'shall', 'won't', 'must' ฯลฯ ต่างก็มีน้ำหนักไม่เท่ากัน ก็ต้องไปดูเรื่องภาษา และหลักกฏหมายประกอบ (เพราะ requirements ที่สิ่งที่ทีม commit กับ stakeholder จึงส่งผลด้านกฏหมายด้วย)

มือโปรก็ยังเป็นมือโปรวันยังค่ำนะครับ แค่ย่อหน้านี้คุณ minimalist ก็จะทำให้โลกของ bdd ที่ผมเคยเห็นเปลี่ยนรูปไปเลย
ถ้า tspec อิมพลีเม้นต์ระบบ priority ตามนี้ มันก็จะกลาย bdd เฟรมเวิร์คที่ล้ำหน้ากว่าตัวอื่น ทั้ง rspect และ jbehave ไปอีกหลายขุมเลยครับ

เดี๋ยวอีก 2-3 วันผมขอลองเล่นแล้วจะมาพูดถึงต่อนะครับ

ทำไปเรื่อย ๆ นะครับ ผมเชียร์สุดใจขาดดิ้นเลย

ป.ล. ไอเดียที่คุณ cblue และ juacompe (SPL + AOP) กำลังทำ มักทำให้ผมขนลุกอยู่เรื่อย 555 เพราะมันเป็นการตอบโจทย์ได้ตรงจริง ๆ

ผม refactor และย้ายโค้ดมาไว้ใน trunk หลัก ตอนนี้อยู่ที่นี่ครับ
http://geogia.googlecode.com/svn/trunk/spec/

ใน directory 'demo' มีตัวอย่างอยู่ 2 ตัวอย่าง

เรื่อง SPL ผมไม่ได้ทำครับ อันนั้นของน้อง juacompe อย่างเดียวเลย ;-)

[minimalist]

ขอโทษด้วยครับไม่เข้าเว็บหลายวันเลย อินเทอร์เน็ตมีปัญหานิดหน่อย

ขอบคุณมากครับสำหรับคำชม

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

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

ขอบคุณมากครับ

[นายข้าวโพดหวาน]

ส่วนสิ่งที่คุณ cblue กำลังทำอยู่ เรื่องข้อจำกัดของภาษาไทยผมว่าไม่มีปัญหาครับ เพราะภาษาไทยก็เป็นภาษาที่มีไวยกรณ์อยู่ ก็น่าจะสร้างเป็น patterns / rules ได้ เช่นน้ำหนักของความต้องการของคำว่า 'ต้อง', 'น่าจะ', 'อาจ', 'ควร', 'might', 'should', 'would', 'could', 'shall', 'won't', 'must' ฯลฯ ต่างก็มีน้ำหนักไม่เท่ากัน ก็ต้องไปดูเรื่องภาษา และหลักกฏหมายประกอบ (เพราะ requirements ที่สิ่งที่ทีม commit กับ stakeholder จึงส่งผลด้านกฏหมายด้วย)

มือโปรก็ยังเป็นมือโปรวันยังค่ำนะครับ แค่ย่อหน้านี้คุณ minimalist ก็จะทำให้โลกของ bdd ที่ผมเคยเห็นเปลี่ยนรูปไปเลย
ถ้า tspec อิมพลีเม้นต์ระบบ priority ตามนี้ มันก็จะกลาย bdd เฟรมเวิร์คที่ล้ำหน้ากว่าตัวอื่น ทั้ง rspect และ jbehave ไปอีกหลายขุมเลยครับ

ผมไม่ค่อยแน่ใจว่าการใช้ requirement levels (อ่านเพิ่มที่ RFC 2119) จะนำมาใช้กับ BDD ได้แค่ไหน อย่างตัวอย่าง psuedo code

CODE

it "should do X given Y" do
  if (Y)
    X
end

กับ

CODE

it "must do X given Y" do
  if (Y)
    X
end

ถ้าใช้ตามความหมาย should เป็นเพียงแค่ guideline ไม่จำเป็นต้องทำ X เมื่อเงื่อนไข Y เป็นจริง ในขณะที่กรณีหลังใช้ must คือต้องทำ X แน่ๆเมื่อ Y เป็นจริง แต่อย่างไรก็ตาม กลายเป็นว่า should กลับไม่มีประโยชน์ในการทำ spec เลย หรือว่ามีไว้เพื่อระบุ warning (กรณี should แล้วไม่เป็นจริง) หรือ failure (กรณี must แล้วไม่เป็นจริง) ถ้าเป็นกรณีนี้การใช้คำที่มีน้ำหนักของ requirement ต่างกัน จะช่วยระบุระดับการเตือนได้ แต่ทั้งนี้ทั้งนั้น การตีความน้ำหนักคำ ต้องเข้าใจตรงกัน มิฉะนั้นจะยิ่งทำให้สับสนมากขึ้น แบบนี้น่าจะใช้คำไสตล์คำที่ใช้ใน Logging อย่าง info, warn, error จะชัดเจนกว่าหรือเปล่าครับ

[cblue]

ผมไม่ค่อยแน่ใจว่าการใช้ requirement levels (อ่านเพิ่มที่ RFC 2119) จะนำมาใช้กับ BDD ได้แค่ไหน อย่างตัวอย่าง psuedo code

ขอบคุณครับ

ก่อนที่จะสร้างระบบ requirements-level ให้ BDD framework ก็คงต้องนิยามกันก่อน
ผมคิดว่า RFC 2119 ที่แนะนำมาช่วยได้มากครับ ไม่ซับซ้อนเกินไป

กรณีการใช้ของ BDD ส่วนใหญ่เท่าที่เห็นแบบเป็น 2 แบบหลัก ๆ ก็คือ
1. behaviour และ
2. story
แต่ใน tspec ผมเตรียมไว้เป็นแบบ story อย่างเดียวครับ ยังไม่ได้คิดไวยากรณ์ที่เหมาะสำหรับแบบ behaviour

ในแบบ story ตอนนี้ใช้คำว่า "ควร" เป็นตัวกำหนดประโยคตรวจสอบ
ซึ่งอาจจะเพิ่มให้ใช้คำว่า "จะต้อง" เพื่อแทนการบังคับ และ

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