TDD

Phát triển hướng kiểm thử TDD (Test-Driven Development) là một phương pháp tiếp cận cải tiến để phát triển phần mềm trong đó kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại mã nguồn (Refactoring).

Mục tiêu quan trọng nhất của TDD là hãy nghĩ về thiết kế của bạn trước khi viết mã nguồn cho chức năng. Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được.

1.TDD là gì?

TDD (Test Driven Development) là một phương thức làm việc, hay một quy trình viết mã hiện đại. Lập trình viên sẽ thực hiện thông qua các bước nhỏ (BabyStep) và tiến độ được đảm bảo liên tục bằng cách viết và chạy các bài test tự động (automated tests). Quá trình lập trình trong TDD cực kỳ chú trọng vào các bước liên tục sau:

1. Viết 1 test cho hàm mới. Đảm bảo rằng test sẽ fail.
2. Chuyển qua viết code sơ khai nhất cho hàm đó để test có thể pass.
3. Tối ưu hóa đoạn code của hàm vừa viết sao cho đảm bảo test vẫn pass và tối ưu nhất cho việc lập trình kế tiếp
4. Lặp lại cho các hàm khác từ bước 1

Thực tế, nên sử dụng UnitTestFramework cho TDD (như JUnit trong Java), chúng ta có thể có được môi trường hiệu quả vì các test được thông báo rõ rang thông qua màu sắc:

• Đỏ: test fail, chuyển sang viết function cho test pass
• Xanh lá: viết một test mới hoặc tối ưu code đã viết trong màu đỏ.

2. 3 điều luật khi áp dụng TDD

1. Không cho phép viết bất kỳ một mã chương trình nào cho tới khi nó làm một test bị fail trở nên pass.
2. Không cho phép viết nhiều hơn một unit test mà nếu chỉ cần 1 unit test cung đã đủ để fail. Hãy chuyển sang viết code function để pass test đó trước.
3. Không cho phép viết nhiều hơn 1 mã chương trình mà nó đã đủ làm một test bị fail chuyển sang pass.

3. Mô hình chu trình TDD

Một chu trình khi áp dụng TDD

Mô hình thông qua màu sắc của unit test framework

Một mô hình khác hướng dẫn áp dụng TDD

4. Các cấp độ TDD

1. Mức chấp nhận (Acceptance TDD (ATDD)): với ATDD thì bạn viết một test chấp nhận đơn (single acceptance test) hoặc một đặc tả hành vi (behavioral specification) tùy theo cách gọi của bạn; mà test đó chỉ cần đủ cho các mã chường trình sản phẩm thực hiện (pass or fail) được test đó. Acceptance TDD còn được gọi là Behavior Driven Development (BDD).
2. Mức lập trình (Developer TDD): với mức này bạn cần viết một test lập trình đơn (single developer test) đôi khi được gọi là unit test mà test đó chỉ cần đủ cho các mã chường trình sản phẩm thực hiện (pass or fail) được test đó. Developer TDD thông thường được gọi là TDD.

5. Các lỗi thường gặp khi áp dụng TDD

• Không quan tâm đến các test bị fail
• Quên đi thao tác tối ưu sau khi viết code cho test pass
• Thực hiện tối ưu code trong lúc viết code cho test pass => không nên như vậy
• Đặt tên các test khó hiểu và tối nghĩa
• Không bắt đầu từ các test đơn giản nhất và không theo các baby step.
• Chỉ chạy mỗi test đang bị fail hiện tại
• Viết một test với kịch bản quá phức tạp

6. Các ví dụ tham khảo về TDD

• Ngắn:
  • Chapter 6 – Agile principles, patterns, and practices in C# – by Martin C. Robert, Martin Micah. Khá thú vị. Xem online tại đây.
  • Phần 3, 4, 5 của Craftsman.
• Trung bình:
  • Part I – Test-Driven Development by example – Kent Beck.
  • Part III – Test-Driven Development: A practical guide – David Astels.
  • Phần 6, 7, 8, 9, 10 của Craftsman.
• Dài:
  • Part II – Test-Driven Development in Microsoft .NET – James W. Newkirk, Alexei A. Vorontsov.
  • Part III – Growing object-oriented software, guided by test – Steve Freeman, Nat Pryce.

7. Các công cụ hỗ trợ

Các công cụ phục vụ cho TDD, thường là các nền tảng cho kiểm thử mã nguồn mức đơn vị (unit test): 

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.

8. Kết luận

Thiết kế dựa trên kiểm thử (TDD) là một kỹ thuật phát triển, trong đó trước tiên bạn phải viết một mã kiểm thử chạy thất bại, trước khi bạn viết mã nguồn cho chức năng mới. TDD đang nhanh chóng được nhiều nhà phát triển phần mềm theo phương pháp Agile chấp nhận để phát triển mã nguồn ứng dụng, và thậm chí còn được thông qua bởi những nhà quản trị cơ sở dữ liệu theo phương pháp Agile (Agile DBA) cho phát triển cơ sở dữ liệu. TDD nên được xem như là bổ sung cho phương pháp phát triển hướng mô hình Agile (Agile Model Driven Development – AMDD) và cả hai có thể được sử dụng cùng nhau. 

TDD không thay thế phương pháp kiểm thử truyền thống, thay vào đó nó định nghĩa một cách thức để đảm bảo việc thực hiện các unit test một cách hiệu quả. Hiệu ứng phụ của TDD là các kiểm thử cung cấp một đặc tả hoạt động cho mã nguồn. TDD được đánh giá tin cậy trong thực tế và được nhiều lập trình viên phần mềm quan tâm và lựa chọn.

Unit Testing

Unit Testing là một trong các thành phần chính của Agile Software Development. Được giới thiệu đầu tiên bởi Kent Beck, unit testing đã trở thành một thành phần không thể thiếu trong các hệ thống của các tổ chứ lớn nhỏ. Unit tests giúp các kỹ sư giảm thiểu số lỗi, thời gian để debugging, góp phần làm tăng sự ổn định, bền vững.
Trong bài viết này, chúng tôi sẽ tìm hiểu các bước để các LTV dùng unit testing trong các hệ thống phần mềm, không liên quan đến ngôn ngữ lập trình hay môi trường phát triển.

1. Unit Test quản lý rủi ro của bạn

Với một newbie, có lẽ sẽ hỏi Tại sao tôi phải viết test? Suy nghĩ Unit test là một việc làm tẻ nhạt, những kỹ sư phần mềm muốn outsource để tránh nó đi. Đó là tâm lý mà không còn chỗ trong công nghệ phần mềm hiện đại. Mục đích của những nhóm phần mềm là sản xuất phần mềm có chất lượng cao nhất.
Khách hàng và những nhà doanh nghiệp luôn than phiền về những lỗi của các phần mềm trong những năm 80 và 90. Nhưng với sự phong phú của các thư viện, dịch vụ web và các môi trường phát triển cung cấp các tính năng như refactoring và unit testing, sẽ không cònn chỗ đứng cho phần mềm có sai sót.
Ý tưởng đằng sau của Unit Test là tạo ra một tập hợp những lớp test cho mỗi thành phần của phần mềm. Unit Test tạo điều kiện thuận lợi cho việc test phần mềm liên tục, không giống những tài liệu về test, sẽ ít tốn kém khi thực hiện chúng nhiều lần.
Unit test sẽ lớn lên theo hệ thống. Mỗi test là một hợp đồng bảo hiểm mà hệ thống làm việc. Việc dùng một tập hợp unit test, những kỹ sư có thể giảm bớt đáng kể số lượng lỗi và nguy cơ với code chưa được test.

2. Viết Test Case trên thành phần cơ bản

Khi bạn bắt đầu sử dụng unit testing, luôn luôn phải hỏi Test là cái gì mà tôi phải viết?
Có một suy nghĩ sai là viết cụm của các hàm test dùng để thăm dò chức năng nào đó trong hệ thống. Bạn phải suy nghĩ rằng: cần tạo một test case (tập hợp các test) cho mỗi thành phần cơ bản nhất.
Tiêu điểm của test là một thành phần tại một thời điểm. Bên trong mỗi thành phần, tìm kiếm một thành phần có thể tương tác – bao gồm các thuộc tính được truy xuất ra bên ngoài. Bạn cần phải viết ít nhất một test trên mỗi phương thức public.

3. Tạo Abstract Test Case và Test Utilities

Với bất kỳ đoạn code nào, ở đây sẽ có những thứ chung mà tất cả các test của bạn cần làm. Bắt đầu với việc tìm thấy unit testing cho ngôn ngữ của bạn. Ví dụ trong java, những kỹ sư dùng Junit - một framework đơn giản nhưng mạnh để viết test trong java. Framework có lớp TestCase, lớp căn bản cho tất cả các test. Thêm vào những phương thức tiện ích thích hợp với môi trường của bạn. Tất cả các trường hợp test đều có thể chia sẽ tài nguyên chung này.

4. Viết những lớp test khôn khéo

Test thì cần nhiều thời gian, vì thế cần đảm bảo là test của bạn hiệu quả. Một lớp test tốt sẽ thăm dò ứng sử chính của mỗi thành phần, nhưng làm việc đó với code ít nhất có thể. Ví dụ, bạn chẳng cần viết test cho phương thức getter và setter trong Java Bean, nhưng nó sẽ vẫn được test thông qua các test khác cần thiết hơn.
Thay vào đó, viết test tập trung vào các ứng xử của hệ thống. Bạn không cần viết một cách hoàn thiện, hãy tạo những test có ý nghĩa bây giờ, rồi để thêm về sau nữa.

5. Thiết lập môi trường trong sạch cho mỗi test

Người ta luôn quan tâm đến hiệu quả. Vì vậy khi nghe rằng test cần thiết lập môi trường riêng rẽ, họ thường lo lắng về cách thực hiện. Tuy thế thiết lập mỗi test chính xác và từ đầu là quan trọng. Đảm bảo rằng mỗi test được thiết lập đúng mức và không lo lắng về hiệu quả.
Trong trường hợp khi bạn có môi trường chung cho tất cả các test - không cần thay đổi khi chạy – bạn có thể thêm static vào lớp test căn bản của bạn

6. Dùng Mock object để test có hiệu quả

Thiết lập test thì ko đơn giản, và cái nhìn đầu tiên thỉnh thoảng dường như không thể đạt được. Ví dụ, nếu sử dụng Amazon Web Services trong code của bạn, bạn có thể mô phỏng nó như thế nào trong lớp test mà không có sự tác động hệ thống thật sự.
Có một số ít cách. Bạn có thể tạo ra dữ liệu giả và sử dụng nó trong những lớp test. Trong hệ thống mà có những người sử dụng, một tập hợp riêng biệt những tài khoản có thể được dùng riêng cho việc test, được gọi là những mẫu hay những Mock object.
Việc chạy test thường xuyên có thể ảnh hưởng đến hệ thống: nếu điều gì đó trục trặc và bạn xoá dữ liệu người dùng thực tế, giải pháp là dùng dữ liệu giả 
Một đối tượng giả thi hành interface đặc biệt, nhưng trả về kết quả đựơc xác định trứơc. Ví dụ, bạn có thể tạo ra đối tượng giả cho Amazon S3 mà luôn luôn đọc đựơc file từ đĩa local của bạn. Đối tượng giả có ích khi test hệ thống phức tạp với nhiều thành phần. Trong Java, có vài framework giúp tạo những đối tượng giả, đáng chú ý là JMock

7. Refactor test khi bạn refactor code

Việc test chỉ đựơc trả tiền nếu bạn thật sự đầu tư vào nó. Không chỉ bạn cần viết test, bạn cũng cần đảm bảo chúng được cập nhật. Khi thêm một phương pháp mới vào một thành phần, bạn cần thêm một hoặc nhiều test tương ứng. Bạn phải làm sạch những code không dùng bên ngoài , đồng thời loại bỏ những test không còn thích hợp nữa.
Unit test đặc biệt có ích khi làm refactoring trên diện rộng. Refactoring tập trung vào việc duy trì tính ổn định của code để giúp nó giữ ở trạng thái đúng. Sau khi bạn chỉnh sửa test, chạy lại các test có liên quan để đảm bảo bạn không làm hỏng bất cứ thứ gì khi thay đổi hệ thống.

8. Viết test trước khi sửa lỗi

Unit test là vũ khí hiệu quả trong sự đấu tranh chống lại những sai sót. Khi bạn sơ hở một vấn đề trong code của bạn, viết test trình bày vấn đề này trước khi chỉnh code. Theo cách này, nếu lỗi lại xuất hiện, nó sẽ bị bắt bởi test.
Điều này là quan trọng vì bạn không thể luôn luôn viết test đúng hoàn toàn. Khi bạn thêm test một sai sót, thì bạn đang lấp đầy lỗ hỏng trong test của chính bạn.

9. Unit Tests đảm bảo tính thực thi

Chẳng nhửng đảm bảo tính chính xác của code, unit tests còn chắc rằng thự thi của code không có suy biến, giúp cải thiện tốc độ thực thi của hệ thống.
Để viết một performance tests, bạn cần implement chức năng start và stop trong test class. Khi thích hợp, bạn có thể dùng một phương thức bất kỳ có liên quan đến thời gian hay code ước lượng thời gian chạy.

10. Test tính đồng thời

Code đồng thời rất khó khăn và là điển hình của source có nhiều lỗi. Đó cũng là lý do mà test này là rất quan trọng. Cách để làm là sử dụng sleep và locks. Bạn có thể viết trong sleep gọi test của bạn nếu bạn cần đợi một trạng thái đặc biệt của hệ thống. Trong khi đây không là giải pháp đúng 100%, chỉ đúng trong một số trường hợp. Để mô phỏng sự đồng thời trong một kịch bản phức tạp hơn, bạn cần lock thành công các đối tượng mà bạn đang test. Vì vậy bạn chỉ có thể mô phỏng hệ thống đồng thời nhưng tuần tự.

11. Chạy Test liên tục

Điểm cần chú ý của test là chạy chúng liên tục, đặc biệt là trong những team lớn, có nhiều người phát triển trên một code căn bản. Bạn có thể thiết lập test để chạy sau vài giờ một lần, hay bạn có thể chạy chúng trên mỗi lần check-in code, hay mỗi ngày (có thể là hằng đêm). Hãy quyết định phưong thức thích hợp nhất cho dự án của bạn và làm những test chạy tự động và liên tục.

12. Vui với Test!

Quan trọng là bạn vui với nó. Lần đầu tiên tôi gặp unit testing, tôi luôn nghi ngờ và nghĩ nó là công việc phụ. Nhưng tôi đã thay đổi cách nghĩ, vì một người rất thông minh mà tôi luôn tin cậy nói với tôi rằng nó rất hữu ích.
Unit testing đặt trí tuệ của bạn vào trong trạng thái mà nó rất khác với trạng thái code. Nó kích thích suy nghĩ của bạn về một việc đơn giản là làm sao tập hợp các test cần thiết cho thành phần này.

EJB Security

Autthentication

-là quá trình xác thực ,nhằm xác định một tài khoản đang vào hệ thống.Nếu không có quá trình xác thực này ,hệ thống của bạn sẽ không biết được tài khoản nào đang truy cập để có các phản hồi phù hợp.

-Cụ thể trong ứng dụng EJB,các server trong EJB sẽ xác thực tài khoản đang đăng nhập thuộc kiểu tài khoản nào và cấp các role cho tài khoản đó.

-Có 2 kiểu xác thực:
 +Digital certificates có thể được sử dụng để xác định người dùng cuối cùng, máy chủ, và các thành phần phần mềm khác.
   +Digital certificate-based authentication có thể được sử dụng trên các máy chủ, khách hàng, hoặc cả hai, tùy thuộc vào nhu cầu của ứng dụng
 Access Control Lists (ACLs)

   -Một cách để kiểm soát truy cập cho người dùng trong một ứng dụng
   -Một tập tin ACL được tạo thành các mục, có chứa một tập hợp các quyền cho một tài nguyên cụ thể và một tập hợp các người dùng có thể truy cập vào các tài nguyên.

Realms

-Realms là một cơ sở dữ liệu đầy đủ của người dùng và nhóm người dùng nhằm  xác định giá trị của một ứng dụng web và được kiểm soát bởi chính sách xác thực như nhau.
-The Java EE server authentication service có thể quản lý người sử dụng trong nhiều lĩnh vực so với các lĩnh vực tập tin, quản trị, lĩnh vực, và lĩnh vực chứng

Users and Principals

-Một user là một cá nhân được quy định tại các máy chủ ứng dụng
-Kiến trúc bảo mật J2EE không đối phó với user nhận dạng trực tiếp. Nó liên quan đến danh tính người dùng trừu tượng.

Groups and Roles

 -Groups là một tập hợp các người dùng xác thực, phân loại theo đặc điểm phổ biến, được định nghĩa trong máy chủ ứng dụng.
 -Roles là hình thức trừu tượng của nhóm.
 -Roles là một cách cụ thể mà người dùng có thể tương tác với một ứng dụng và nó cũng xác định các quyền truy cập mà người dùng phải có để thực hiện tương tác này
-Từ roles, ta thực sự biết người dùng là ai và vai trò của người dùng

Managing Users

-Users, groups, and roles được quản lý bởi các máy chủ ứng dụng
-Một ứng dụng sẽ nhắc người dùng nhập tên đăng nhập và mật khẩu của họ trước khi cho phép họ truy cập vào một tài nguyên được bảo vệ
-Sau đó, ứng dụng chuyển thông tin đến máy chủ.

 Roles in EJB development

-Bean provider: Người cung cấp cái bean đó
-Application assembler : Người đóng gói ứng dụng lại
-Deployer: Sau khi đóng gói rồi thì sẽ triển khai cái ứng dụng đó trên server tương ứng
-Product provider: Người phát triển sản phẩm sau khi được khai triển
-Systen administrator: Người quản trị hệ thống

MDB

ACT_DevEJB_Assignment_M14_v1.1

Alpha is the name of a mail-order company. You are part the team that isdeveloping a solution for automating the processes involved between order logging, invoicing, and the shipment of goods. You have to develop a message-driven bean that acts as an intermediary between the sub-systems that constitute the solution. Each of the subsystems is implemented in the form of entity beans. The first subsystem is where the orders are logged. As soon as the order is registered, a message is sent from the Order subsystem to the message-driven bean. The message-driven bean, in turn calls the other two subsystems, Invoicing and Shipping to proceed with the order. In other words, the message-driven bean that you develop should act as a trigger for the other two subsystems. 

Bước 1:Tạo Jms theo các bước như sau:

Bươc 2: Tạo mới 1 java web application,gồm các thành phần sau:

Bước 3: Tạo JSF Managed Bean,chuột phải chọn Insert code /SendMessage chọn tới Jms resource ta vừa tạo trên .

Bước 4:code cho file index.xhtml

Bước 5:chạy ta được giao diện như sau,và nhập dữ liệu và gửi thông tin đi

Bước 6: Tạo EJB Module có tên consumer

Bước 7: Tạo  Message Driven Bean để nhận và hiển thị ra message 

Assignment architecture jpa ejb jsf

Bước 1:Tạo mới java web application, gồm các thành phần sau:

Bước 2:Chuột phải source code /new /Persistence/Entity class from database và thực hiện theo các bước dưới đây

Bước 3: Chuột phải source code /new /Persistence/JPA Controller

Bước 4: Trong Jpa TblUser ta triên khai code  hàm checkLogin

Bước 5: Trong Jpa Post ta triên khai code  hàm getAllPost(),và getPostByTitle()

Bước 6: Tạo mới Session Bean có tên là TblUserManager,triền khai code như sau

Bước 7: Tạo mới Session Bean có tên là PostManager,triền khai code như sau

Bước 8 :Tạo mới JSF Manages Baean co tên Login.java và triển khai code như sau:

Bước 9 :Tạo mới JSF Manages Baean co tên ShowAllPost.java và triển khai code như sau:

Bước 10 :Code cho trang view : index.xhtml và home.xhtml

Kết quả:

JMS

Prac-assignment

 TechSchool Solutions designs software systems for schools. One of the problemsthat the schools face is teacher absenteeism or teachers taking leaves on a short  notice. The schools find it difficult to call substitute teachers in such a short time. TechSchool Solutions is planning to build a system which would enable the school teachers to request for leaves using the school portal. The system would then send an e-mail to all the substitute teachers that have been registered in the system. As a member of the development team, you are required to build the JMS-based module. Your tasks involve developing a session bean that acts as a message listener and receives a message from the JMS queue whenever a teacher puts in a leave request. The session bean, then calls other modules that handle rest of the processes.

Bước 1:Mở trình duyệt gõ localhost:4848

Chọn Destination Resource

Chọn New

Bước 2: Tạo mới 1 java application :MyteachProducer,trong đó ta tạo Java Managed Bean :producerBean

Bước 3: Trong  producerBean insertcode /sendMessage

Bước 4:Code cho trang view index.xhtml

Bước 5: Tạo mới 1 java application :MyteachCónsummer,trong đó ta tạo Java Managed Bean :BeanConsumer

Bước 6: Trong  Beanconsumer  insertcode /sendMessage

Bước 7:Code cho trang view index.xhtml

Kết quả:

Session Bean

Apply to assignment,login user story


Bước 1:Tạo java web application ,gồm các thành phần sau

Bước 2:Tạo 1 DBConnection class để kết nối với database ,và hàm checkLogin

Bước 3:Tạo Session Bean class va triền khai code như sau:

Bước 4: Tạo JSF Managed Bean class,và xử lý code cho controller này

Bước 5:Gọi EJB trong class login,đẻ sử dụng phương thức check Loin của enterprise java bean

Bước 6:Code cho trang view index.xhtml ,home.xhtml

Kết quả:

Nhận xét:

 -Stateless bean không lưu trạng thái giao tiếp của client

-Bạn có thể sử dùng stateless bean để thực hiện bất cứ action nào trong ứng dụng

-Stateful bean có khả năng giữ lưu trữ trạng thái giao tiếp của client