Nghiên cứu và ứng dụng phương pháp đặc tả phần mềm bằng ví dụ trong phát triển phần mềm

Với mục đíc cứu, thử nghi và đ xuất cách thức để triể k a ươ pháp này trong thực tiễn của công ty Cổ ph n Ph n m m Vi t Quốc Tế, đã lựa chọ đ tài "Nghiên cứu và ứng dụ p p áp đặc tả phần

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

HÀ NỘI, 2015

LỜI CA Đ AN

T x ca đoa l vă ày là ững nghiên cứu của bản thân tôi Những kiến thức trong lu vă ày được thể hi n dựa trên vi c tổng hợp các kiến thức từ nhi u nguồn, từ những kinh nghi m thực tế khi ể c c ự của c y à đa là

vi c

Mọ được trích dẫn trong lu vă đ u tuân theo lu t sở hữu trí tu và

lu t bản quy n tác giả, được li t kê mộ c c đ y đủ chính xác

Tôi xin hoàn toàn chịu trách nhi m với những nội dung viết trong lu vă ày

Học viên thực hi n

T

LỜI C N

Tôi xin bày tỏ lòng biế ơ sâ sắc đến tất cả mọ ườ đã ú đỡ, hỗ trợ tôi thực

hi n lu vă ày, x cả ơ oa a Đ Học, T ườ Đ Học C N , Đ Học

Q ốc G a Hà Nộ đã c o và o đ u ki để tôi thực hi n lu vă ày

Tôi xin chân thành cả ơ sự ú đỡ và chỉ bảo t n tình của Th y o, T ế s

Hồ Tườ , ả v ướng dẫn của tôi Th y đã c ỉ bảo, đị ướng nghiên cứu thực hi n, hỗ trợ, t o nhữ đ u ki n tốt nhất cho tôi trong suốt quá trình thực hi đ tài

Tôi xin bày tỏ lòng biế ơ sâ sắc đế ữ ườ â o a đ đ c

là ố, M , Chồ đã o đ u ki , động viên, ủng hộ trong những lúc khó k ă để tôi có thể hoàn thành lu vă ày

Xin chân thành cả ơ ất cả quý Th y, C o oa, T ườ đã n tình chỉ bảo, rèn luy n, truy đ t những tri thức, k ă , k m quý báu cho tôi trong suố

ữ ă ọc vừa qua

Học viên thực hi n

T

C L C

MỞ ĐẦU 1

1 C ươ 1: Tổ q a v A le 3

1.1 G ớ v A le 4

1.2 Tuyên ngôn Agile 4

1.3 N y lý của A le 6

1.4 Đ c ư của A le 7

1.4.1 Tí l (I e a ve) 7

1.4.2 Tí ế (I c e e al) và ế óa (Evol o a y) 8

1.4.3 Tí íc ứ ( ay íc – Adaptive) 8

1.4.4 N ó ự ổ c ức và l c ức ă 8

1.4.5 Q ả lý ế ực (E cal ocess Co ol) 8

1.4.6 G ao ế ực (Face-to-face communication) 9

1.4.7 ể ựa ị ( al e-based development) 9

1.5 TDD 10

1.5.1 Lịc sử 10

1.5.2 Ý ưở 11

1.5.3 Nguyên lý 11

1.5.4 Quy trình 14

1.5.5 C cụ ỗ ợ 15

1.5.6 í ụ ọa 15

1.5.7 Đ 20

1.6 ATDD 21

1.6.1 Lịc sử 21

1.6.2 Ý ưở 21

1.6.3 Nguyên lý 22

1.6.4 Quy trình 24

1.6.5 C cụ ỗ ợ 26

1.6.6 í ụ ọa 27

1.6.7 Đ 28

1.7 BDD 29

1.7.1 Lịc sử 29

1.7.2 Ý ưở 29

1.7.3 Nguyên lý 30

1.7.4 Quy trình 31

1.7.5 C cụ ỗ ợ 32

1.7.6 í ụ ọa 32

1.7.7 Đ 38

1.8 Tổ ợ TDD, ATDD, DD 39

2 C ươ 2: ươ đ c ả ằ ví ụ 41

2.1 Lịc sử 41

2.2 Ý ưở 41

2.3 Nguyên lý 42

2.3.1 X c đị v ừ ục 43

2.3.2 Đ c ả y c ộ c c cộ c o ó ực ự 46

2.3.3 M ọa sử ụ ví ụ 48

2.3.4 Là ị đ c ả 50

2.3.5 Tự độ ẩ đị à k c ay đổ đ c ả 51

2.3.6 T ẩ đị ườ x y 55

2.3.7 L ục ế óa à l ố 57

2.4 Quy trình 58

2.5 C cụ ỗ ợ 63

2.6 í ụ ọa 64

2.7 o s Đ c ả ằ ví ụ và UML 64

2.8 Đ 65

2.8.1 C c c ức của v c là ày ay 65

2.8.2 N ữ lợ íc à ươ đ c ả q a ví ụ a l để vượ q a c c c ức 66

2.8.3 Đ ể yế 67

2.8.4 Đ của độ ự 67

3 C ươ 3: T ử và đ v c đưa ec f ca o y Exa le vào ực ế 69

3.1 Mục đíc 69

3.2 Q y ể c c ự II 69

3.2.1 Đ c đ ể ự 69

3.2.2 M ể 70

3.2.3 M cả ế ụ đ c ả q a ví ụ 74

3.2.4 ươ ụ ớ vào o c c độ ự o c

ty 77

3.3 T ực q ể eo ec f ca o y Exa le 78

3.3.1 Đố vớ ữ ự đa o q ể 78

3.3.2 Đố vớ ự " ể we s e ướ ẫ lịc " 80

3.3.3 Dự ử 94

3.4 Đ 94

3.4.1 Đ của ả â 94

3.4.2 Đ của độ ự 95

KẾT LUẬN 96

DANH M C TỪ VIẾT TẮT, THUẬT NGỮ

Test Driven Development ể ướ k ể ử

Empirical Process Control Q ả lý ế ực

Face to face communication G ao ế ực

Value based development ể ựa ị

ANH C NG I H NH

H NH

H 1.1 Mộ số ươ A le 3

H 1.2 C c â đo n l đ l p l i trong Agile 7

H 1.3 Mức độ phổ biến của c c ươ 2009 – 2010 [9] 10

H 1.4 TFD Cycle [13] 12

H 1.5 TDD cycle and Traditional Cycle [10] 13

H 1.6 TDD step [15] 14

H 1 T o o ec k ể ử 15

H 1 T lớ ss ess 16

H 1.9 Lớp nghi p vụ 18

H 1.10 Lớ đố ượng dữ li u trung gian 19

H 1.11 Thêm tham chiếu 19

H 1.12 Acceptance - Test Driven Development (ATDD) Cycle [6] 23

H 1.13 Chu kỳ đơ ản của ATDD [12] 25

H 1.14 ATDD và TDD [12] 26

H nh 1.15 ATDD trong mô hình l p [12] 26

H 1.16 Mối liên h của BDD, ATDD, TDD 40

H 2.1 Mô hình của specification by example [3] 42

H 2.2 M x c đị v ừ ục 44

H 2.3 T o câ c y ườ sử ụ [3] 45

H 2 M ọa sử ụ ví ụ 49

H 2.5 Mộ đ c tả có thể tự động thực hi n với Concordion[3] 52

H 2.6 Mộ đ c tả có thể thực được với FitNesse[3] 52

H 3.1 M ể 70

H 3.2 T o o ec k ể ử 86

H 3.3 Cà đ s ec flow 86

H 3 Cà đ s ec 87

H 3.5 T o f le fea e 87

H 3 T o kịc ả 88

H 3 T o s e c o kịc ả – ước 1 88

H 3 T o s e c o kịc ả – ước 2 89

H 3.9 T o s e c o kịc ả – ước 3 89

H 3.10 C y kịc ả 91

NG I

ả 3.1 C ấ lượ ự ừ 2 đế 4 79

ả 3.2 ả v ự ể we s e ướ ẫ lịc 83

Ở Đ

Tính cấp thiết và quan trọng của đề tài

Hi n t đa là l p trình viên t i một công ty phát triển ph n m m với g n

400 nhân viên Trong những dự án mà tôi tham gia, tôi thấy có những vấ đ sa đa ồn

t i:

 c à ườ ay ay đổi yêu c , c c ươ ể đa được

áp dụng không thích nghi nhanh với nhữ ay đổi này

 Sản phẩ k được à ao đú ời h n

 Sản phẩ k đú với yêu c u của ười sử dụng

 Chấ lượng sản phẩm thấ o k được kiểm thử ườ x y , cơ c ế kiểm thử tích hợ c ưa ốt

 Mất nhi c í để duy trì những tài li u của dự án

 Chi phí phát triển, kiểm thử lớn

T đa k ếm mộ ươ ển có ể ả q yế ữ vấ đ trên, phù hợp vớ đ c thù của những dự án trong công ty, có thể đưa ự đến thành

c , đe l i lợi nhu n và thỏa mãn yêu c u của khách hàng Th y ướng dẫn của tôi, tiế s Hồ Tườ đã c ỉ c o ươ "Đ c tả bằng ví dụ", mộ ươ tuy t vời có thể giải quyết những vấ đ ả k ể ự đã ở

Với mục đíc cứu, thử nghi và đ xuất cách thức để triể k a ươ pháp này trong thực tiễn của công ty Cổ ph n Ph n m m Vi t Quốc Tế, đã lựa chọ đ

tài "Nghiên cứu và ứng dụ p p áp đặc tả phần mềm bằng ví dụ trong phát triển phần mềm"

Mục tiêu của đề tài

 Nghiên cứu và tìm hiểu nhằm hiể õ c c ươ : ể

ướ k ể ử (TDD – Test Driven Development), ể ướ

k ể ử c ấ (ATDD – Acceptance Test Driven Development), ể

ướ ành vi (BDD – Behaviour Driven Development) và Đ c tả bằng

ví dụ (Specification by example)

 Đ xuất cách thức để triển khai ươ pháp này trong môi ường thực tiễn của công y Cổ Q ốc Tế

Luậ vă đ ợc trình bày với những phầ sau đây

 C 1 Tổng quan về Agile: Trình bày các khái ni cơ ản của phát triển

ph n m m linh ho t Agile Trình bày nguyên lý, quy trình của c c ươ phát triển linh ho t: TDD, ATDD, BDD

 C 2 Đặc tả bằng ví dụ: Trình bày các khái ni cơ ả , ý ưởng, nguyên

lý, quy trình của ươ Đ c tả bằng ví dụ

vào thực tế: Mô tả ươ ực hi n dự án ụ đ c ả ằ ví ụ

Kết quả của nghiên cứ đã ực hi n những vấ đ trên, tuy nhiên

ể đ x ấ vẫ c oà và sửa đổ c o ợ vớ c c ự , đả ảo à

c của ự

1 C 1 Tổ qua về Agile

Đ c ả ằ ví ụ là ộ ươ o ữ ươ ể

m l o A le (Agile software development - ọ ắ là A le)

Agile không phải là mộ ươ à là ột h thống các triết lý, nguyên tắc, giá trị Agile giố ư ột chiếc ô với nhi ươ k c a ư: c , X (Extreme programming), Crystan, DSDM (Dynamic System Development Method), TDD (Test Driven Development), ATDD (Aceptance Test Driven Development), BDD (Behaviour Driven Development), Specification By Example

H 1.1 Mộ số ươ A le

C c ươ TDD, ATDD, BDD có c ướ đ vớ ươ đ c ả

ằ ví ụ, đ ướ đế xây ự đú sả ẩ ựa v c k ể ử ự độ , xây

ự đú y c TDD ườ được ể eo ướ k ể ử ự độ ức đơ vị, ATDD là k ể ử ự độ ức c ấ sả ẩ , DD c có ể được ể là ộ ATDD, ư DD có đị a cụ ể ữ ả c c đ k c ấ Đ c ả

ph n m m hoàn thành, có thể là 6 tháng, 1 ă , 2 ă , ó đã k đ ứ được yêu

c u, ho c do chỉ được à ao c o k c à vào a đo n cuối của dự án nên không

có được phản hồi v vi c sản phẩ có đ ứng yêu c u hay không Mộ ươ phát triển ph n m m linh ho A l e đã a đờ để giải quyết những vấ đ trên

1.2 Tuyên ngôn Agile

T a ă 2001, ười bảy nhà phát triển ph n m m (Kent, Beck Mike Beedle, Arie van BenneKum, Alistair Cock burn, Ward Cunning ham, Martin Flowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brain Marick, Robert C.Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas) đã p gỡ nhau ở ow , U a Reso để thảo lu n v c c ươ ển ph n m m gọn

nh và linh ho t Họ đã c ố Tuyên ngôn Phát triển ph n m m linh ho ( Manifesto for Agile of wa e Develo e – gọi tắ là Tuyên ngôn Agile ) để đị a c c hiểu v Phát triển ph n m m linh ho t.[1]

đó để c c ó ày cấ ườ ựa c

ầ mềm c ạy tốt à tà ệu đầy đủ

v a ước k sả ẩ oà à Chìa khóa cho sự thành công là sự hợp tác

m nh m với khách hàng và một hợ đồng mà chi phối sự hợ c đó ơ là cố gắ để

x c định các chi tiết ph m vi và lịch trình vớ một chi phí cố định

1 Ư cao ấ của c ú là ỏa ã k c à q a v c c yể ao

sớ và l ục c c có ị

2 C ào đó v c ay đổ y c , c í ấ ộ o q ể C c

q y l o ụ sự ay đổ c o c c lợ ế c a của k c à

3 T ườ x y c yể ao c y ố ớ k c à , ừ và đế và , ư c o c c k oả ờ a ắ ơ

4 N à k oa và à ể ả là v c c a à ày o s ố ự

án

10 ự đơ ả là c ế – ố đa óa lượ c v c c ưa oà à

T ay v lo lắ v ữ vấ đ s của ữ c v c c ưa c oà

à , độ ự ực ữ c v c đơ ả ấ , ợ vớ ục ,

vớ c ấ lượ cao ấ , ễ à ay đổ ế có vấ đ s o ờ a tiế eo

l p kế ho ch, phân tích yêu c u, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau)

để cho ra các ph n nhỏ của sản phẩm [9]

H 1.2 C c â đo l đ l l o Agile

1.4.2 Tí t ệm t ế (I c eme ta ) và t ế óa (Evolutionary)

C ố ỗ â đo l , ộ ỏ của sả ẩ được oà à , có k ả

ă c y ố , đã được k ể ử N ữ ày được à ao ay c o k c à để

c y ử, lấy được ý k ế ả ồ của k c à và có ữ đ c ỉ íc ợ để

sả ẩ đa được ể đú vớ ục của ó C c â đo ày ố ế

a , ừ của sả ẩ được oà à , sả ẩ được íc l y c o đế k sả

ẩ đ ứ được oà ộ y c c của k c à N ư v y, sả ẩ lớ l

eo ờ a và ế óa đế k à [9]

1.4.3 Tí t íc ứ ( ay t íc – Adaptive)

Do c c â đo n chỉ kéo dài trong một khoảng thời gian ngắn, và vi c l p kế

ho c c được đ u chỉnh liên tục, c c ay đổi trong quá trình phát triển (yêu c u

ay đổ , ay đổi công ngh , ay đổ đị ướng v mục tiêu v.v…) đ u có thể được đ ứng theo cách thích hợp Ví dụ, trong Scrum – ươ ổ biến nhất hi n nay – trong khi nhóm phát triển sản xuất ra các gói ph n m m, khách hàng có thể đưa c c yêu c u mới, chủ sản phẩm (Product Owner) có thể đ c c y c u này và có thể đưa vào là v c o â đo (được gọi là Sprint trong Scrum) tiế eo T eo đó, các quy trình Agile ường thích ứng rất tốt vớ c c ay đổi [9]

1.4.4 N óm tự tổ c ức và ê c ức ă

Cấu trúc nhóm Agile ường là liên chức năng (Cross-functionality) và tự tổ chức

(Self-organizing) T eo đó, c c ó ày ự thực hi n lấy vi c phân công công vi c mà

không dựa trên các mô tả cứng v chức danh (title) hay làm vi c dựa trên một sự phân cấp

rõ ràng trong tổ chức Các nhóm này cộng tác vớ a để ra quyế định, theo dõi tiế độ, giải quyết các vấ đ mà không chờ m nh l nh của các cấp quản lý Họ không làm vi c

eo cơ c ế nh l nh và kiể so (co a a co ol) N ó ự tổ chức có a

là ó đã đủ c c k ă (co e e cy) c n thiết cho vi c phát triển ph n m m, do v y nó

có thể được trao quy để tự ra quyế định, tự quản lí và tổ chức lấy công vi c của chính

để đ được hi u quả cao nhất [9]

1.4.5 Quả ý t ế t t ực ệm (Emp ca cess C t )

Các nhóm Agile ra các quyế định dựa trên các dữ li u thực tiễn thay vì tính toán lý thuyết hay các ti n giả định (prescription) Vi c phân nhỏ dự à c c â đo n ngắn góp ph a ă c c đ ểm mốc để nhóm phát triển thu th p dữ ki c o đ u chỉnh các chiế lược phát triển của mình Nói cách khác, Agile rút ngắ v đời phản hồi

(short feedback life cycle) để dễ à íc và a ă í l o t Theo thời gian, các chiế lược này s tiến g đến tr ng thái tố ư , ờ đó ó có ể kiể so được tiế , và â cao ă s ấ lao động [9]

1.4.6 G a t ếp t ực d ệ (Face-to-face communication)

Một số mô hình phát triển ph n m m dựa rất nhi u vào công vi c giấy tờ, từ vi c thu th p yêu c ười dùng, viế đ c tả h thống, các thiết kế h thống v.v Agile không phả đối công dụng của công vi c tài li óa, ư đ cao ơ v c giao tiếp trực

di n thay vì gián tiếp thông qua giấy tờ V yêu c u của khách hàng, Agile khuyến khích nhóm phát triển trực tiếp nói chuy n vớ k c à để hiể õ ơ v ữ khách hàng thực sự c n, thay vì phụ thuộc nhi u vào các lo vă ản Trong giao tiếp giữa nội

bộ nhóm phát triển với nhau, thay vì một l p trình viên (thực hi n vi c v ế ã) và mộ k

sư ( ực hi n vi c thiết kế) giao tiếp với nhau thông qua bản thiết kế, Agile khuyến khích

a ười này trực tiế ao đổi và thống nhất với nhau v thiết kế của h thống và cùng nhau triển khai thành các chức ă eo y c u

Bản thân các nhóm Agile ường nhỏ (í ơ ườ a ười, một nhóm lớn

ườ được phân nhỏ vớ cơ c ế hợ c đ c để l l có lượng giao tiếp

tố đa) để đơ giản hóa quá trình giao tiế , úc đẩy vi c cộng tác hi u quả Các dự án lớn muốn dùng Agile ường phải phân thành nhóm nhỏ đồng thời làm vi c vớ a ướng đến một mục tiêu chung Vi c này có thể đ ỏi một số nỗ lực đ kể trong vi c đ u phối các mức ư ữa các nhóm

Các nhóm phát triể ường t o a c c ó q e và cơ c ế ao đổi trực di n một

c c ường xuyên Mộ o c c cơ c ế ường thấy là các cuộc họp t p trung hằng ngày (Daily meeting, Daily Scrum, Standup meeting) T đây, ất cả c c à v được yêu c u nói rõ cho nhóm của mình biế đã là , đa là , sắ là và đa

g p phả k ó k ă ào o q là v c cơ c ế ày được thực hi n hi u quả, nhóm luôn luôn nắ được tình hình công vi c của mình, có các à động thích hợ để vượt qua các trở lực để thực hi n thành công mục tiêu của dự án [9]

1.4.7 át t ể dựa t ê á t (Value-based development)

Một trong các nguyên tắc cơ ản của Agile là n m m ch y tố c í là ước

đo của tiế độ N y ắc này giúp nhóm dám lo i bỏ đ c c c v c ư ừa không trực tiếp mang l i giá trị cho sản phẩm

Để v à được cơ c ế là v c dựa trên giá trị , ó Agile ường làm vi c trực tiế và ường xuyên vớ k c à ( ay đ i di n của khách hàng), cộng tác trực

tiếp với họ để biết yêu c u nào có độ ưu tiên cao hơn, mang l i giá trị ơ sớm nhất có

thể cho dự án Nhờ đó c c ự án Agile ường giúp khách hàng tố ư óa được giá trị của dự án Một cách g ư ực tiếp, Agile a ă đ kể độ hài lòng của khách hàng [9]

Sự phát triển của Agile

Theo khảo sát của hãng nghiên cứu thị ường Forrester, mức độ phổ biến của Agile hi đa ở mức cao nhất, và gấp nhi u l n so vớ c c ươ y n thống

ư c ước hay CMMI (xem Hình 1.3) Hơ ế, một số ươ Agile có xuất

xứ và được sử dụng hi u quả ngoài ph m vi phát triển ph n m m

đã k ế c o TDD được chấp nh n và phổ biến trong cộ đồng phát triển ph n m m Sở

ó TDD đ được chuẩn hóa l i bởi Kent Beck bở TDD đã được đ c ước đây o k oa ọc máy tính từ nhữ ă 19 0, thời kỳ của mainframe [10]

Sự k c a cơ ản của TDD ước đây và TDD o e eck đưa a là: T ước đây quá trình k ể ử được thực hi n thủ công, còn TDD ngày nay k ể ử được tự động hóa bởi cộng cụ k ể ử ự độ

TDD hi đ đ đã được thực hi n trên cộ đồng Smalltalk với công cụ Smalltalk SUnit Do cộ đồng Smalltalk rất nhỏ nên a đo n này TDD vẫ c ưa được phổ biến

TDD thực sự cất cánh là từ k ó được ứng dụng trên cộ đồng java với bộ công

cụ JUnit JU được viết l i từ ý ưởng của SUnit bởi chính Kent Beck và một số ười khác Với sự phổ biến của nó, các bộ công cụ với các n n tảng khác l lượ được a đời với tên gọi chung là XUnit bao gồm các cộng ngh ư: H , R y, y o o JavaSc …

[Pass, ngừng phát triển]

Kết thúc lập trình dựa trên yêu cầu

Viết tất cả các kiểm thử tự động

Chạy kiểm thử

Kết thúc

Kết quả

Sửa lỗi

H 1.5 TDD cycle and Traditional Cycle [10]

ự k c a cơ ả c í là ả c ấ v ế k ể ử ước k v ế ã của TDD

ớ ươ y ố c ỉ v ế k ể ử k đã v ế ã xong N ư v y k ể

ử c ỉ đơ là x c l ã đã v ế

ịc ả k ể ử ớ ấ v c ức ă đó c ưa được xây ự

 Dựa vào o ố của kịc ả k ể ử, ườ ể s xây ự ộ

lượ ã ồ vừa đủ để l c y ứ 2 của kịc ả đó à c

T o c c ước trên ước chuẩn hóa mã nguồ (Refac o ) c í là đ ểm

m nh chính của ươ TDD Nó vừa đảm bảo cho ã ồ oà à đú y

c a đ u, l i vừa được cấu trúc l để cải tiến chấ lượng ã theo các chuẩn

1.5.5 C cụ ỗ t ợ

C c c cụ ỗ ợ TDD có c là XUNIT vớ c c c , ữ l

t k c a ư: cppUnit, csUnit (.Net), CUnit, DUnit (Delphi), DBFit, DBUnit, HTMLUnit, HTTPUnit, JMock, JUnit, NDbUnit, NUnit, OUnit, PHPUnit, PyUnit (Python), SimpleTest, TestNG, Test::Unit (Ruby), VBUnit, XTUnit [13]

1.5.6 í dụ m ọa

ể ự eo ươ TDD, c ú a c v ế k ể ử ước k

l p trình Ở đây s lấy ộ ví ụ vớ ộ c ức ă đơ ả của ố ể lịc T o lịc ể c (Schedule master) vớ ữ : Tên-Mục đíc chuyế đ , ữ đấ ước s đ q a, ững thành phố s đ q a, ngày khởi hành, ngày trở

v

ể ố ày đế sử ụ 3 lớ vớ As e v y

s sử ụ As e và ộ f a ewo k k ể ử đã íc ợ s ở s al tudio 2013

T s ả c v c ả là k ể c c lớ vụ

ớc 1: Tôi v ế kế c o c ức ă ày Tôi c o ộ lớ vụ

c o c ức ă o c e le: ScheduleBLL Cô v c đ c là là o k ể ử

c o lớ c e le ày

T o 1 ự leA , 1 o ec c o ao : SimpleApp, 1 poject BussinessLogic Layer, 1 o ec để k ể ử lo c ày là ss essLo cLaye Tes

H 1.7 T o o ec k ể ử

///<summary>

///Gets or sets the test context which provides

///information about and functionality for the current test run

//Step 1: Call function Create data

String themOftravel = "Du lich 30-04-test";

String ownerId = "4f69707d-00bb-4a76-a907-1d3294846b94";

CreateSchedule dataTest = newCreateSchedule();

dataTest.HandleName = "PhuongBT";

dataTest.ThemeOfTravel = themOftravel;

dataTest.DepartingDate = DateTime.Now.AddDays(3);

dataTest.ReturningDate = DateTime.Now.AddDays(7);

dataTest.OwnerId = ownerId;

ScheduleBLL(Configs.ConnectionString);

scheduleLogic.Create(dataTest);

//Step 2: Check in database

var resultSchedule = scheduleLogic.FindByName("Du lich 30-04");

if (resultSchedule != null)

Assert.AreEqual(dataTest.HandleName,

resultSchedule.HandleName);

else Assert.Fail("Create Fail");

//Step 3: Delete data test

v c ưa ồ lớ c e le LL c ư ươ ức C ea e của ó

Tôi v ế được ươ ức k ể ử ư v :

Tôi c ộ lớ q ả lý lo c vụ của c e le, v y c 1 lớ

c e le LL ở BusinessLogicLayer T o ày, tôi o ộ e face

I c e le LL vớ ươ ức c ea e c e le, sa đó o lớ c e le LL ực

e face ày:

H 1.9 Lớ vụ

Tôi ằ ươ ức ày c 1 a số là 1 sche le được y ừ lớ ao

ước 2: Ch y kiểm thử và thấy ươ ức kiểm thử mới thất b i

ước 3: T ực v ế ã ồ để ươ ức k ể ử đú

ước 4: ước sa đó tôi s ố ư ã ồ của để ươ ức k ể

ử vẫ đú

V ế k ể ử ước ư v y, khi tôi o c sửa 1 í ă k c, o c ay đổ

cấ úc ữ l …Tôi s ế , v c ay đổ có là ả ưở đế ữ í ă tôi đã

c ATDD và co ó ư là k ực tế trong tiến trình phát triển ph n m m Lý do vẫn

là c ưa x ất hi n bộ công cụ có thể k ể ử tự động lên vi c áp dụng ATDD vẫ được coi là rất khó k ă

C o k oảng từ ă 2003 tới ă 2004: với sự a đời của bộ công cụ hỗ trợ ATDD Fit/FitNesse, một công cụ hỗ trợ viết k ể ử tự động, ATDD mới d n d được

những gì chúng ta c n cung cấp cho khách hàng dựa trên các chức ă của ph n

m m.TDD đã k ải quyế được vấ đ , và đây là lý o c í ATDD a đời

ATDD xuất phát từ c , q a đ ểm của ười dùng ứng dụng, một cái nhìn từ bên ngoài h thống Họ kiể a c ươ ừ oà ư sự chính xác của đ u ra

k đưa ộ đ u vào cụ thể ATDD là một ph n trong ữ chiế lược kiểm tra tổng thể

h thố ước k à ao c o ười dùng cuối

ATDD được x c định từ sự cộng tác của khách hàng với các nhà phát triển và nhà kiểm thử, và được t o ước khi thực hi n viết mã, ó được dùng trong suốt quá trình phát triể c ư k oà à sản phẩm, kiểm thử tích hợp, kiểm thử h thống ATDD không phải kiểm thử chấp nh n truy n thống được thực hi n bở ười dùng cuối sau khi hoàn thành sản phẩ , để x c định sản phẩ có đ ứ đ c tả trong hợ đồng hay không ATDD c k ải kiểm thử h thố được viết bởi kiểm thử viên khi họ đọc yêu

c để chắc chắn h thố đã là đú y c u [7]

1.6.3 Nguyên lý

Do được mở rộng và cải tiến từ ươ TDD, ATDD c đ eo c c ếp

c n v ế k ể ử ước k v ế ã l ATDD được t o khi yêu c đã được phân

íc xo , và ước khi vi c l được tiến hành Các kịch bản do ATDD t o ra phản ánh cách hành xử mong muốn của sản phẩm ph n m m Độ ự s t o ra một ho c nhi u kịch bản k ể ử cho mỗi chức ă ước khi bắ đ u thực hi n chức ă đó

T ường các kịch bản này s được thảo lu và được thống nhất khi làm vi c cùng ười dùng, nhà phân tích nghi p vụ

T ường các kịch bả ày được viết bằng cách sử dụng các thu t ngữ thống nhất trong độ ể sao cho k c à , l v , và k ể ử v có thể cùng hiểu

N ư v y ATDD và yêu c u nghi p vụ có ánh x trực tiếp với nhau

Bất cứ yêu c u nghi p vụ nào mà thiếu c c ca k ể ử ươ ứ đ u có thể

k được kiểm tra mộ c c đú đắn N ược l i bất cứ ca k ể ử nào mà không ứng với yêu c u nghi p vụ ào đ u coi là thừa, không c n thiết Khi chức ă được thực hi

xo à c c ca k ể ử k à c co ư y c ươ ứng vớ ca k ể

ử đó k được thực hi n mộ c c đú đắn.Bất cứ ca k ể ử nào phát sinh sau quá trình chức ă đã ực hi đ u coi là yêu c u mới

N ư v y ATDD đã là ăng sự phối hợp trong quá trình t o ra sản phẩm ph n

m m Nó giúp chúng ta t o ra sản phẩm chính xác những gì khách hàng yêu c u ngay từ

đ u

H 1.12 Acceptance - Test Driven Development (ATDD) Cycle [6]

ATDD được sinh ra trong ngữ cảnh Agile, vì v y vi c thực hi n nó chủ yếu trong

các dự án theo mô hình Agile

- Đ ểm xuất phát của ươ ATDD là ừ yêu c ười sử dụng mà trong mô

hình Agile gọi là câu c y ườ Tất cả các yêu c u s được chuyển hóa

thành các câ c y ườ , mỗi câ c y ườ s mô tả một cách

ngắn gọ ư đ y đủ một chức ă à thống s phải thực hi n

- ATDD s được thực trên câ c y ườ và ươ ứng với câ c y

ườ N ư v y c ư câ c y ườ , ATDD s là nhữ đ c tả

cho những hành vi và chức ă à thống s thực hi n ATDD s nói cho ta

biết, với mỗi câ c y ườ , cách h thống s đ u khiển dựa đ u

vào, đ u ki n cụ thể s c o đ a ươ ứng

- ATDD có các thuộc tính sau:

 Được sở hữu bởi khách hàng

 Được viết với sự phối hợp giữa khách hàng, l p trình viên và kiểm thử viên

 Nó diễn tả h thống làm gì (What) chứ không mô tả cách h thống thực hi n

(How)

 Được diễ đ t dựa trên ngôn ngữ mi n, o đó có ể dễ à được hiểu bởi tất

Ví dụ cho t ường hợ ày để dễ hiểu: Rất dễ để viết ATDD cho các ứng dụng web thông qua giao thức HTTP với bất cứ ngôn ngữ phổ biế ào, ư đ u này l i không

đú đối với các h thống kiểu nhúng

Lý do chính khác cho vi c chọn ngôn ngữ triển khai ATDD khác với ngôn ngữ cài

đ t h thống là yêu c u cho viế ATDD ường rất khác so với các yêu c u c để thực hi n h thống Ví dụ một h thống thời gian thực (real-time) có thể rất dễ để l p trình với chỉ ngôn ngữ C trong khi nó l ơ k ó để diễ đ t ATDD bằng ngôn ngữ C sao cho khách hàng, nhà phân tích nghi p vụ có thể hiể và ó T o ường hợp này các ngôn ngữ ướng kịch bả ay được chọ để sử dụng

Các ngôn ngữ cho vi c diễn tả ATDD ường s ở d ng khai báo, các cấu trúc bả , được thể hi n ưới d ng chuỗi của c c à độ được diễn tả bằng ngôn ngữ Tiếng Anh Nếu chúng ta mong muốn khách hàng phối hợp ch t ch với nhà phát triển trong vi c thực hi n ATDD, những ngôn ngữ cấp thấp mang nhi u tính k thu t ư: Java, C, C++, C# s không phải là lựa chọn tốt

1.6.4 Quy trình

Có rất nhi u cách khác nhau ứng dụ ATDD ư đ c tả thông qua các ví

dụ, DD… Dướ đây là ột trong các cách dựa trên ATDD

C c đơ ản và tự nhiên nhất của ATDD theo mô hình sau:

H 1.13 C kỳ đơ ả của ATDD [12]

Chu kỳ này s được l p dựa trên danh sách các câ c y ườ Bắ đ u từ

vi c lấy một câ c y ườ , viết ca k ể ử cho câ c y ườ này, chuyển ca k ể ử này ch y ở chế độ tự động dựa trên một công cụ ch y k ể ử tự

độ N ư v y ta có mộ ca k ể ử có thể ch y tự động ứng với yêu c u câ c y

ườ đã c ọn Cuối cùng thực hi n v ế ã để thỏa ã ca k ể ử này

- ước 1: Lấy 1 câ c y ườ (user story) trong product backlog Vi c

chọn câ c y ườ dựa trên mô hình Agile, lấy câ c y ườ thực hi n trong sprint hi n hành

- ước 2: Viế c c ca k ể ử để thỏa mãn câ c y ườ này Trong giai

đo n này có sự a a của k c à , ười xác nh đ u ki n thỏa mãn câ

c y ườ , k ể ử v , và l p trình viên

- ước 3: Tự độ óa c c ca k ể ử đã v ết ở ước trên: ước này liê q a đến

công cụ được chọ để tự động hóa vi c k ể ử

- ước 4: Thực hi n l p trình chức ă để thỏa ã ca k ể ử T o ước này

l p trình viên bắ đ u v ế ã c o chức ă ATDD k q y định rõ cách thực

hi ước này Tuy nhiên mục đíc vẫn là ã được viế đủ để thỏa mãn ca k ể

ử đã được đị a

H 1.14 ATDD và TDD [12]

V cơ ản các ước này dựa trên mô hình ATDD đã ả ở trên T eo ươ pháp này, l p trình viên luôn luôn yêu c k c à ư vấn ở tất cả c c ước sao cho sản phẩm làm ra thỏa ã đú y c u khách hàng càng sớm càng tốt

Do ATDD được sinh ra trong ngữ cảnh Agile nên vi c ứng dụng nó trong môi ường Agile là đ u rất tự nhiên [12]

H 1.15 ATDD tron l [12]

1.6.5 C cụ ỗ t ợ

Concordion, FitNesse, Robot Framework

đưa a ữ đ k c ấ c o câ c y ườ

Đưa ra ữ câ ỏ ảo l vớ k c à để ợ a ữ đ k c ấ

c o câ c y ườ :

- h ng trư ng thông tin n o b t buộc?

=> Them Of Travel, HandlName, Departing Date, Countries

- h ng trư ng thông tin n o giới h n t ?

=> Them Of Travel (10 t ), HandlName (10 t )

- g tháng phải định d ng như th n o n c th ấ v dụ hông?

=> dd/MM/yyyy

- u turning at trước ng parting dat th ngư i dùng c th t o đư c ịch bi u hông?

hông t o đư c, đưa ra thông báo ng tháng hông h p

- ịch bi u đư c t o ra mặc định ở tr ng thái p n phải hông?

ước ày y ộc vào f a ewo k c ọ để ự độ óa k ể ử Độ ự

c ọ Specflow ữ g đ k c ấ s được v ế ướ fea e và sce a o ố vớ DD s ày ở ế eo

ớc 3: Tự độ óa k ể ử c o c c đ k c ấ đã v ế được ở ước

Nế ở ước 2, c ọ ecflow v c ự độ óa ày c ố vớ DD s

- Do ATDD nhấn m nh vào sự phối hợp giữa khách hàng, l p trình viên, kiểm thử

viên, nên ươ ày cải tiế đ kể sự hiểu biết lẫn nhau trong độ ự

và hiểu biết v sản phẩm Sản phẩ là a đ ứng chính xác những gì khách hàng yêu c u

- Do ATDD nhấn m đến vi c k ể ử tự động, v ế k ể ử ước khi v ế ã,

bất cứ lỗ ào s đ u có phản hồi rất nhanh từ ười sử dụng cuối

- Đây là ấn m đến sự chia sẻ trách nhi m, hiểu biết giữa khách hàng

và nhóm phát triển

- Mọi yêu c ười sử dụ đ được làm rõ ngay từ đ u pha phát triển, l p trình

viên luôn t vào đú ững gì khách hàng yêu c , được ư ừa

- Dự án có thể đo đ c dễ dàng các chỉ tiêu dựa trên tỉ l ATDD thành công và thất

b i

Đ ểm yếu

- Do ươ ấn m nh vào sự c n thiết phải có khách hàng tham gia, nên s

có k ó k ă k k c à n

- Khi phải viết k ể ử tự động, l p trình viên s phải làm nhi u vi c ơ

truy n thống khi họ chỉ phải viết mã chức ă

- Có thể thời gian thực hi n dự án bị ch m ở a đo đ u do có công vi c phân tích

yêu c u, tự động hóa k ể ử phát sinh

- í q ả: P ươ ế c ày c ỉ có q ả k có sự a a của

k c à vào q ể ự N ược l q ả của ó k

so vớ c í ỏ a để ực đã có k c à a a, í k ả của ự cao ơ ẳ T à v o ự l ế đa là , đó

Trong một hội nghị t Lo o vào 11 ă 2009, Da No đã đưa a định

a DD ư là ế h tiếp theo của TDD a đó Dan North cùn đồng nghi đã o

ra công cụ để thực óa ươ DD với tên là JBehave, tiếp theo là RBehave cho Ruby Ông cùng David Chelimsky, Aslak Hellesoy và nhữ ười khác tiếp tục phát triển RSpec và viết cuố s c T e R ec ook: e av o D ve Development with

R ec, C c e , a F e s ướng dẫn cách áp dụng BDD, sau phát triển thành Cucumber bởi Aslak Hellesoy

C o ă 200 C s Ma s đã ể eo ý ưởng Feature Injection cho phép BDD tham gia vào cả ph n phân tích nghi p vụ và toàn bộ chu trình phát triển ph n

m m từ xây dự ý ưở a đ u, l c o đến chuyển giao