Hiendt's Weblog

Đã hơn 2 năm từ khi Hiendt's blog ra đời. Có những lúc tôi như muốn buông việc update cho blog, vì quá bận. Rất nhiều bạn đã động viên tôi, và cũng xin cảm ơn các bạn rất nhiều về điều đó.
Năm 2008 đã sắp qua đi, và ta cùng chào đón một năm mới. Tôi xin cầu chúc cho các bạn và gia đình luôn khỏe mạnh, và một năm mới thành công. Sau đây là một số thông tin thu thập của blog này.

Hiendt's blog - Top keyword

Hiendt's blog - Top pages view

Hiendt's blog - Top refering

Hiendt's blog - Top visitor

Đọc tiếp >>

Chúng ta đều biết đến ca sĩ người Bỉ gốc Việt này qua ca khúc “Bonjour Vietnam”. Nhân dịp cô ca sĩ rất Việt này về thăm quê, thân gởi đến các bạn một bài PV được sưu tầm trên blog của PQA.

Đọc tiếp >>

Một người bạn gởi cho tôi. Tôi đã cố tìm kiếm nguồn chính xác trên internet, và có một số thông tin bên dưới, nhưng cũng chưa rỏ tác giả thực sự.

Tuy nhiên, nó sẽ đem đến cho bạn những kinh nghiệm khi test.
Nếu bạn hỏi tôi, tôi sẽ nói ả - một tester xuất sắc (đôi khi còn bị gọi là “Test dị nhân”) - là một người mà:

Lạng lách

Tester xuất sắc phải là tay chuyên “lạng lách”. “Lạng lách” là ở chỗ: ai cũng có thể làm theo danh sách dài dằng dặc những test cases có đầy rẫy trong các sách dạy testing, nhưng tester xuất sắc lại có thể đi xa hơn cả cái danh sách này, và với tới một seri bất tận những phương pháp xương xẩu để acttack một chương trình.
Tester xuất sắc thường được giới developers phán là “đáng ớn” và “chập cheng”!

Tò mò

Cái gì cũng có thể khiến một tester xuất sắc quan tâm. Mụ ta luôn muốn hiểu tại sao mọi thứ lại diễn ra theo cách mà nó đang diễn ra. Các bug tốt nhất (hay tệ nhất, tuỳ xem anh ở phe nào) là kết quả của sự tương tác giữa hai cái gì đó của phần mềm (ứng dụng, mô đun, component, hay bất cứ cái gì). Mụ biết rõ: việc hiểu cách mà cái gì đó hoạt động sẽ trực dẫn đến việc hiểu cách mà nó tương tác với một cái gì khác, và hiểu tương tác nào trực tiếp đưa đến bug. Mụ thường bộc lộ tính tò mò trong muôn mặt đời thường: thị trường hoạt động thế nào? Dàn giáo được xây dựng ra sao? Sao lại cho chất phụ gia vào bêtông? Bút chì màu được sản xuất thế nào? v.v.
Tính ham hiểu biết của một tester xuất sắc là không có giới hạn.

Phấn khích bởi bugs

Với một tester xuất sắc, bug là liều thuốc bổ. Mụ ló mặt vào bàn của developer, cười ngoác đến tận mang tai mà phô diễn cái lỗi kinh dị sắc bén nhất mới tìm ra. Mụ khoe khoang về bug của mình với các tester khác và háo hức đón nghe những thành tích chói lọi của đồng ... bọn :-)

Biết rằng luôn luôn còn lỗi

Một tester xuất sắc biết rõ: không có lúc nào mà một ứng dụng lại hoàn toàn không có lỗi. Mụ hiểu rằng một ứng dụng trông như không có lỗi lại chính là một ứng dụng đầy những lỗi chưa được tìm ra. Mụ luôn hăm hở tìm ra những kiểu bug mới. Mụ xem mỗi bug khách hàng tìm ra như một một dấu hiệu của một lớp bug mới mà mụ đã bỏ sót mất.
Vui duyên mới không quên nhiệm vụ (Stays on track)
Tester xuất sắc biết rằng phải làm việc tập trung mới có thể tìm ra và cô lập các bug để lần tới tận nguyên nhân gốc rễ. Mụ ta không bỏ qua những lỗi nhâm tiện tìm ra trên đường đi “truy sát” một bug nào đó, nhưng biết hoãn chỉ tay day mặt chúng cho tới khi cái bug hiện tại bị nắm chắc trong tay. (Và, dĩ nhiên là, sẽ háo hức nói lại với tay developer liên quan, rồi khoe khoang cả với các ả test khác)

Khoanh vùng thoả đáng (Scopes appropriately)

Tester xuất sắc hiểu rõ là không thể có đủ thời gian để thực hiện hết mọi test case muốn thực hiện. Mụ bèn phân mức ưu tiên và khoanh vùng việc test sao cho đảm bảo rằng những lỗi dễ ảnh hưởng tới khách hàng nhất sẽ được tìm ra trước tiên.

Bắt nhầm còn hơn bỏ sót (Investigates weird behavior)

Tester xuất sắc chủ động theo dõi những sự kiện lạ. Các icons không xuất hiện đúng vị trí? Các radio buttons không nằm cùng cụm? Đó chỉ là những lỗi lập trình rất đỗi phổ thông! Nhưng với tester xuất sắc thì: những sự lạ như vậy, tuy có thể xảy ra, nhưng mà là dấu hiệu của một loạt lỗi cẩu thả, không dung thứ được. Với mụ, không phải “Đời lúc nào chả lắm sự bất thường” mà “Á chà, tình hình lại ra nông nỗi này đây!”. Phải chặn ngay!

Tả lỗi chính xác

Tester xuất sắc cặm cụi chăm chỉ để mô tả một cách sáng sủa nhất, ít thao tác nhất cái tiến trình sinh ra một bug. Mụ test đi test lại để xem thực sự thì cái bug đó là gì. Lời mụ tả lỗi chỉ ra rành mạch và chính xác: đâu là sự thật đã được kiểm chứng và đâu là phần ước đoán của tester.

Đồng cảm với khách hàng

Tester xuất sắc khắc cốt ghi tâm cái sứ mệnh làm tầng rào chắn cuối cùng để bảo vệ khách hàng khỏi một sản phẩm không đáp ứng được nhu cầu. Tester xuất sắc hiểu mọi lĩnh vực của khách hàng. Hiểu khách hàng cần làm gì và hiểu khách hàng muốn sử dụng sản phẩm theo cách nào. Tester xuất sắc vượt lên trên cả nhu cầu của khách hàng để nhìn thấy khả năng một sản phẩm có thể cải tiến hoạt động của khách hàng ra sao. Tester xuất sắc truyền bá quan điểm của khách hàng qua suốt vòng đời của sản phẩm, từ vision ban đầu đến pha phân tích yêu cầu, xây dựng chức năng, thay đổi chức năng, chữa lỗi rồi phát hành sản phẩm và đi vào bảo trì. Tester xuất sắc giúp nhóm phát triển sản phẩm hiểu khách hàng như chính họ.

Ưu tiên đại cục

Tester xuất sắc thực sự thân thuộc với mọi chi tiết của mỗi tính năng. Và cũng hiểu mỗi tính năng phù hợp hay ảnh hưởng đến toàn bộ sản phẩm như thế nào? Tester xuất sắc sẵn sàng thay đổi hoặc thậm chí cắt bỏ một số tính năng để làm cho sản phẩm tốt hơn về tổng thể.

Bỏ con săn sắt bắt con cá rô (Picks their fights)

Tester xuất sắc thừa nhận rằng: fix tất cả các lỗi thường là việc quá tốn kém, so với các nguồn lực phải bỏ ra. Thế là mụ cân đo lỗi này so với lỗi khác, cho phép một số lỗi bị ỉm để các lỗi khác được fixed xong.

Giữ vững lập trường (Stands their ground)

Tester xuất sắc biết rõ đâu là những lỗi buộc phải fixed. Mụ sẵn sàng trở nên ngoan cố, bướng bỉnh, xù lông nhím khi cần thiết để đảm bảo rằng một lỗi cần fixed phải được fixed thực sự. Mụ bình tĩnh chỉ ra tại sao lỗi đó phải được fixed và thuyết phục đội phát triển rằng thực tình lỗi đó không thể để lờ đi.

Có thể hỏi developer rằng nhà vệ sinh ở đâu

Những người khách ngoại quốc thường được khuyên làm quen với ngôn ngữ và phong tục của người bản xứ, tới mức đủ để có thể gọi xe về khách sạn, hỏi đường tới nhà vệ sinh, và biết rằng hành động bắt tay ở nước sở tại là lịch thiệp hay bất nhã. Cũng như vậy, tester xuất sắc quen thuộc với ngôn ngữ và tập quán của developer. Tester xuất sắc biết UML đủ nhiều để hiểu được các biểu đồ, để vẽ một class hay vẽ một một biểu đồ tuần tự mà không khiến developer cười sằng sặc. Một tester xuất sắc cũng có thể viết code với trình độ ít nhất là bằng sinh viên năm thứ nhất. Và hiểu các thuật ngữ trong thiết kế ở mức đủ tốt để tham dự được các buổi thảo luận và review thiết kế (chứ không phải xin phép rời phòng họp).

Biết rằng tính khả test (testability) chỉ là một trong nhiều ràng buộc

Tester xuất sắc biết rõ cách duy nhất để thực sự test được một ứng dụng là đưa tính khả test vào mọi khía cạnh của sản phẩm. Mụ phân tích tính năng, thiết kế, kiến trúc phần mềm, và phát triển hàng loạt các ý tưởng để đảm bảo rằng sản phẩm có thể test. Tuy nhiên, mụ cũng biết tính khả test không phải là yếu tố duy nhất ảnh hưởng tới kiến trúc, thiết kế và tính năng. Mụ cân bằng tính khả test với các yếu tố khác và giúp đội phát triển tạo ra giải pháp dung hoà tốt nhất.

Biết khi nào cần sự hỗ trợ

Tester xuất sắc thích thử thách, thích húc đầu vào tường và từ từ đâm thủng nó. Tất nhiên, có một số bức tường dày hơn hẳn những bức khác, và đôi lúc cái lỗ thủng thử thách của nó khiến tester liên tục thất bại. Đó là lúc tester xuất sắc nhận ra cần có sự giúp đỡ và mạnh dạn đề nghị được giúp đỡ. Một tester xuất sắc biết chọn ai để nhờ giúp đỡ, và hiểu rõ không có gì phải xấu hổ khi kêu cầu sự giúp đỡ.

Dành thời gian học tập

Tester xuất sắc biết rõ cách duy nhất để tiếp tục trở thành một tester xuất sắc là không bao giờ ngừng học. Không giới hạn sự học của mình trong ngành test, mụ còn mày mò nghiên cứu về lập trình, về quản lý dự án, về marketing, và về bất cứ thứ gì khác, miễn là có mối quan hệ xa gần tới qui trình sản xuất phần mềm.

Không bao giờ dừng test

Tester xuất sắc vượt quá cả biên giới của những tính năng hiện có để liên tục test sản phẩm được giao. Test cả các sản phẩm khác. Test cả sách, cả tủ lạnh, cả đèn điện, cả cửa ra vào ..., test bất cứ thứ gì trong bất cứ lĩnh vực nào của cuộc sống, rồi phán “Thế là không đúng rồi!”

Đọc tiếp >>

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.

Nguồn: ReadWriteWeb

Đọc tiếp >>

Đối với những người chưa từng dùng unit testing, ý tưởng của mock objects có thể gây khó hiểu. Tôi cũng có một bài viết về mock object, nhưng về cơ bản thì cũng khá lan man. Trong bài viết này, tôi sẽ nói về mục đích cơ bản của mocking. Mock object là gì? Nó dùng để làm gì? Vì sao ta không thể mock cho object XYZ? Trả lời những câu hỏi này sẽ lý giải một cách dể hiểu về mock objects.

Code không chỉ chứa bản thân

Khi học lập trình, các objects mà ta tạo ra chỉ chứa những gì là của nó. Thường thì các helloworld không có sự phụ thuộc vào bên ngoài (trừ System.out nhé). Tuy nhiên, trên thực tế, phần mềm là có lệ thuộc. Tôi viết một action classes phải phụ thuộc vào services, services phụ thuộc vào data access objects (DAOs) và những cái khác nữa.
Ý tưởng của unit testing là để test code ta viết mà không có phụ thuộc. Là một bước để chắc rằng code bạn viết đúng mà không tính đến các phụ thuộc. Giả thiết rằng code tôi viết là đúng như thiết kế và các phụ thuộc cũng vậy, vì vậy khi tích hợp sẽ làm việc tốt theo thiết kế. Lấy ví dụ một đoạn code sau:

import java.util.ArrayList;

public class Counter {
     public Counter() {
     }

     public int count(ArrayList items) {
          int results = 0;

          for(Object curItem : items) {
               results ++;
          }

          return results;
     }
}

Là một ví dụ quá đơn giản, nhưng nó có thể minh họa cho điều này. Nếu bạn muốn test phương thức count, bạn sẽ viết một test để minh chứng cho phương thức count làm việc. Bạn sẽ không phải test ArrayList vì chúng ta đều thừa nhận rằng nó đã được test và làm việc đúng. Bạn chỉ cần test cách bạn dùng ArrayList.
Hãy nhìn vào một đoạn code phức tạp hơn một chút, nó là một đoạn của một ứng dụng trong thực tế:

public class MichaelsAction extends ActionSupport {

     private LookupService service;

     private String key;

     public void setKey(String curKey) {
          key = curKey;
     }

     public String getKey() {
          return key;
     }

     public void setService(LookupService curService) {
          service = curService;
     }

     public String doLookup() {
          
          if(StringUtils.isBlank(key)) {
               return FAILURE;
          }

          List results = service.lookupByKey(key);

          if(results.size() > 0) {
               return SUCCESS;
          }

          return FAILURE;
     }
}

Nếu ta muốn test phương thức doLookup, ta chỉ cấn viết test cho nó mà không cần viết cho phương thức lookupByKey. Nhưng làm sao test doLookup mà không cần chạy lookupByKey?

Dùng Mock Objects

Mock objects dùng khi ta muốn tạo một object và đặt nó tại vị trí của object thực. Nó chắc chắn sẽ chứa phương thức sẽ được gọi với các tham số và cách ứng xử nhất định, nó sẽ trả về kết quả được mong chờ. Dùng đoạn code trên như một ví dụ, giả sử rằng khi tôi gọi và gởi khóa 1234 đến service.lookupByKey được gọi, tôi sẽ có một List được trả về với 4 giá trị. Khi đó, mock object của ta mong chờ rằng khi lookupByKey sẽ được gọi với tham số "1234", nó sẽ trả về một List với 4 objects trong đó.

Mock Objects làm việc thế nào?

Có nhiều mocking frameworks khác nhau trong Java. Tôi sẽ không nó cụ thể về chúng ở đây. Tuy nhiên, tôi sẽ nói về cách nó làm việc và ý tưởng thiết kế mà bạn cần quan tâm khi hiện thực nó.
Về cơ bản thì có hai kiểu của mock object frameworks, một được hiện thực thông qua proxy (bạn có thể hiểu nó như một class ủy nhiệm) và một qua class remapping (map phụ thuộc trực tiếp trong file .class ).
Ta xét cách đầu tiên và là cách được dùng nhiều trong thực tế, proxy.
Một proxy object là một object được dùng thay thế cho object thực. Trong trường hợp của mock objects, một proxy object được dùng để mô phỏng object thực mà code của bạn phụ thuộc vào. Tạo một proxy object với mocking framework, và tiêm nó vào trong object dùng setter. Đây là một điểm cần có trong mocking dùng proxy objects, bạn cần cho phép (public) set phụ thuộc. Nói cách khác, khi bạn tạo một sự phụ thuộc bằng cách gọi new MyObject() thì sẽ không còn chổ cho mocking với một proxy object. Đó cũng là lý do Dependency Injection frameworks như Spring ra đời. Nó cho phép tiêm proxy objects mà không cần phải thay đổi code.
Kiểu thứ hai của mocking là remap file class trong class loader. Tôi chỉ biết duy nhất có jmockit làm việt theo cách này. Nó khai thác một khái niệm mới (có trong JDK 1.5) và được cung cấp trong java.lang.Insturment. Nó sẽ tương tác trực tiếp với class loader để remap sự phụ thuộc đến class file mà nó sẽ load. Giả sử bạn có class MyDependency với tên tương ứng .class là MyDependency.class và tôi muốn viết một mock cho nó dùng MyMock để thay thế cho một object được khai báo sẳn. Bằng cách dùng mock objects, bạn sẽ trực tiếp remap trong classloader với phụ thuộc từ MyDependency đến MyMock.class. Sau đó, mock objects có thể được tạo bằng cách gọi new. Dù cho phương pháp này mạnh hơn là dùng proxy object, nhưng nó khó hiểu và có thê gây bối rối, bạn cần có một kiến thức tốt về classloaders nếu muốn dùng hết các tính năng trong nó.

Kết luận

Mock objects có một giá trị lớn trong testing. Cho bạn khả năng test những gì bạn viết mà không liên quan đến sự phụ thuộc.

Nguồn: http://www.michaelminella.com/testing/the-concept-of-mocking.html

Đọc tiếp >>

Bạn không thể sống với họ, nhưng càng không thể sống thiếu họ. Thích hay không, hầu hết chúng ta phải đối phó với một ông sếp, và cách chúng ta làm không chỉ ảnh hưởng đến tiến bộ sự nghiệp của chúng ta và cả lương mà còn tốt cho tinh thần. Sau đây là một số mẹo vặt để đối xử tốt hơn với sếp của bạn.

1. Hãy nhớ rằng: sếp là người hiểu biết

Bạn nghĩ rằng sếp không có khả năng đó? Hãy nhớ lời nói của Mark Twain, ông ta nói rằng khi 14 tuổi, cha của ông là người ngớ ngẩn đến nổi anh ấy không chụi nổi. Rồi anh ấy lớn lên, khi 21 tuổi, ông đã hết sức ngạc nhiên về những kiến thức mà ông ấy học được từ cha chỉ trong 7 năm. Hãy nghĩ rằng sếp của bạn thông minh hơn bạn nghĩ, và có thể đã từng ở vị trí của bạn, bạn sẽ đánh giá đúng sự việc. Dù không, một ông chủ xấu vẫn có thể đưa ra lời khuyên tốt.
Tôi nhớ những gì mà sếp đã nói với tôi vài năm trước. Ông ấy nói rằng tôi cần năng nổ hơn và làm bất cứ điều gì có ích hơn là nghỉ ngơi sau khi làm việc và chờ phân công việc mới.
Bạn vẫn có thể học từ ông sếp tệ. Phân tích tại sao ông tệ và quyết tâm tránh xa những điều đó nếu bạn muốn trở thành ông chủ tốt.

2. Nhận biết mục tiêu của sếp

Những người phát triển phần mềm thường quan tâm đến “mục đích”. Yêu cầu cả hệ thống phần mềm phải trực tiếp hoặc gián tiếp được dùng. Hay nói một cách khác là tìm ý nghĩa của từng đoạn code, để loại bỏ dư thừa.
Việc gì cũng vậy, cần cố gắng để nhìn thấy bức tranh to lớn hơn. Bạn cần biết cái gì sếp mong chờ ở bạn. Và cần biết rằng làm sao để công việc của bạn giúp ích cho sếp. Hãy chắc rằng những điều bạn đang làm không chỉ phù hợp với mô tả chi tiết công việc của bạn mà còn giúp đỡ sếp hoàn tất mục tiêu của ông ấy.

3. Cần biết những điều mà sếp mong chờ ở bạn

Khi tôi còn trẻ, có một lần tôi phàn nàn mẹ rằng: Con không có việc gì để làm hết mẹ à! “Calvin”, bà ấy trả lời, “Tại sao con không chơi piano đi?” Và đó là lần cuối cùng tôi phàn nàn với bà ấy về chủ đề đó.
Bạn có thể không biết những ước mơ của cha mẹ bạn là tốt đẹp khi bạn là đứa trẻ, nhưng không biết những mong đợi của sếp có thể sẽ phá hỏng sự nghiệp của bạn. Làm sao bạn có thể có thành tích tốt nếu bạn không biết mục tiêu của nó? Và nếu bạn biết mục tiêu, bạn có xác định chúng được ko?
Thỉnh thoảng, hãy kiểm tra với sếp về việc bạn đang làm? Khi bạn đã hoàn thành cái gì đó và chắc rằng sếp của bạn cũng nghĩ vậy. Nếu sếp bạn đã đánh giá về thành tích của bạn, đều đó sẽ tốt cho cả hai, vì vậy bạn có thời gian để sửa đổi khi sai hướng.
Trong thế giới của sự hoàn hảo, không bất ngờ nào có thể xảy ra trong suốt quá trình làm việc của bạn. Và nếu xảy ra, có thể là do sếp của bạn không truyền đạt tư tưởng, hay bạn thất bại trong việc tìm hiểu chúng. Đừng để điều đó xảy ra với bạn.

4. Chậm sửa đổi

Đừng trở thành một “nhân viêc có vấn đề”, có một người sếp luôn luôn phải kiểm tra và theo sau. Để thay thế, cố gắng là một người mà sếp có thể tin tưởng. Điều đó có thể không thấy rõ ràng ngay lập tức, nhưng người sếp tốt sẽ thừa nhận và đánh giá cao điều đó.
Bạn có đang hoàn tất hoàn thành công việc của bạn? Dĩ nhiên là ko? Bạn hầu như mắc sai lầm và tạo ra vấn đề ít nhất 1 lần. Tuy nhiên, khi điều đó xảy ra, bạn hãy đi gặp sếp của bạn. Cố gắng không báo cáo những vấn đề. Hãy nghĩ ra vài giải pháp và chuẩn bị đưa ra đề nghị về kế hoạch của bạn đến sếp.

5. Đừng làm sếp ngạc nhiên

Đừng để sếp nghe được một điều xấu về bạn. Nói cách khác, nếu bạn đã gây ra vấn đề hay mắc phải sai lầm. Tốt hơn hãy trực tiếp nói với sếp – không phải từ khách hàng, từ đống nghiệp và càng không phải từ chính sếp của sếp bạn. Bạn có phủ nhận sự ảnh hưởng đó không? Ngay sau đó, hãy gọi cho sếp của bạn và yêu cầu lời chỉ dẫn tường tận.

6. Bày tỏ lòng biết ơn với sếp về sự thành công của bạn

Khi khoảnh khắc đó đến: Bạn là đại diện cho nhóm của bạn, tiếp nhận khen thưởng hay thừa nhận khác từ sếp hay sếp của sếp bạn. Việc thích hợp để làm tại thời điểm này là biết ơn những người đã làm cho nó được như vậy, đặc biết là sếp bạn. Cho biết rằng điều đó thật dễ dàng khi sếp bạn sẵn sàng giúp đỡ. Dù sếp bạn không làm được gì, hãy cố gắng nói một điều gì đó, nhưng đồng thời bạn chắc chắn điều đó phải đúng sự thật.
Hãy nhớ những gì chúng ta đã thảo luận ở trên – thậm chí một ông sếp tồi có thể đưa ra những lời khuyên tốt. Sếp của bạn làm bạn chán nản hay làm một điều gì đó khó khăn? Có lẻ, trong trường hợp này, bạn có thể cảm ơn sếp đã giúp đỡ bạn “giữ cho mọi thứ triển vọng” hay để “kiểm tra sự minh mẩn” hay giúp đỡ bạn “nhìn thấy vấn đề từ nhiều điểm”.

7. Đừng chỉ trích bản thân

Hầu hết chúng ta quá phức tạp với công việc của mình, rằng nó cứng nhắc và khó tách rời bản thân ra khỏi nó. Vì vậy khi một người nào đó phê bình công việc của chúng ta. Chúng ta quan niệm sự phê bình như là sự công kích cá nhân. Cách phản ứng đó có thể gây cản trở sự phát triển của và sự tiến bộ của chúng ta.
Khi sếp của bạn (hay người khác) phê bình công việc của bạn, cố gắng giả vờ như công việc đó được làm bởi một người khác. Và rồi, khảo sát nghiên cứu nó như là một người thứ ba có thể và kiểm tra giá trị của lời phê phán đó.
Một ông chủ thông minh sẽ thấy rõ sự thành công của bạn ràng buộc đến sự thành công của sếp ông ấy. Bởi vậy, cho nên sếp có sự quan tâm trong viêc làm của bạn. Hơn nữa, lời phê bình từ sếp có thể là một dấu hiệu mà sếp có những mông đợi cao hơn từ bạn.
Khi tôi bắt đầu làm việc, tôi đã bị lật đỗ bởi vì sếp của tôi giao cho tôi nhiệm vụ mà tôi suy nghĩ là quá khó khăn. Tôi bàn luận sự quan tâm của tôi với bạn của cha tôi, người đã từng làm việc trong lĩnh vực giống như tôi đang làm. Tôi vẫn nhớ lời khuyên của người bạn đó. “Cavin” ông ấy nói rằng: “[tên của sếp] đã giao cho bạn nhiệm vụ đó bởi vì ông ấy nghĩ rằng bạn có thể làm công việc đó tốt”.

8. Hãy nhớ rằng sếp của bạn cũng có sếp.

Chúng ta đã thảo luận trước đó sư quan trọng của việc biết những mục tiêu của sếp bạn. Trong tĩnh mạch như vậy, ý thức được rằng sếp của bạn có một ông sếp nữa. Bạn có thể sử dụng thực tế kia để xây dựng mối quan hệ cộng tác với sếp của mình, việc có mối quan hệ cộng tác kia đưa cho sếp bạn có ấn tượng tốt hơn về bạn và cho bạn cái nhìn rõ ràng về sếp của sếp bạn.

9. Đừng chỉ trích sếp

Việc chuyển chỉ trích sếp bạn có thể giới hạn sự nghiệp của bạn. Bởi vậy, cẩn thận việc chỉ trích sếp của bạn ở nơi công cộng, như người đã làm với cha tôi. Trong khi ông ta đang làm cộng sự cho một nhóm biểu diễn. Ông ta đã nói đến Viện Bách Khoa Worcester. Nhưng lại phát âm nó như “Woo-ster”. Người đó đã nói: “Wellington, bạn đã sai”. Nó là “Woo-ches-ter.” Thật may mắn, cha tôi đã nhanh trí làm lệch lời bình luận với câu trả lời sau đây: “Tôi lấy làm tiếc, xin tha lỗi cho tôi. Tiếng anh chỉ là ngôn ngữ thứ năm của tôi”. Sự khôi hài của cha tôi đã hủy bỏ hoàn cảnh đó.

10. Quản lý sếp của bạn khi cần thiết

Vươn lên trong sự nghiệp bằng cách hãy làm nhiều hơn là ngồi lại và chờ đợi những mệnh lệnh. Bạn phải có sáng kiến, tìm kiếm những cơ hội để giải quyết các vấn đề. Tận dụng bất kỳ tổ chức nào mà sếp của bạn có mối quan hệ. Giải thích với sếp về những kế hoạch của bạn và tại sao chúng quyết định cho doanh nghiệp thành đạt.
Yêu cầu sếp đấu tranh với bất kỳ cuộc chiến quan liêu nào có ảnh hưởng đến bạn. Hãy biết rằng, sếp là sếp, và bạn đang định hướng sếp, người đang có lợi thế mà bạn không có.

Nguồn: http://blogs.techrepublic.com.com/10things/?p=284

Đọc tiếp >>

Cách tốt nhất để học một framework mới là viết một ứng dụng HelloWorld dùng nó. Tôi xin bắt đầu theo cách này, viết một HelloWorld portlet dùng Spring Portlet MVC Framework. Để đơn giản, ứng dụng HelloWorld của tôi chỉ có mode View. Bất cứ khi nào người dùng truy cập đến HelloWorld portlet, chúng ta chỉ hiển thị trang View.jsp.

portlet.xml

Hãy bắt đầu với file portlet.xml trong webapp/WEB-INF/ như sau:

<?xml version="1.0" encoding="UTF-8"?>
<portlet-app
        xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
        version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd 
        http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd" >
<portlet>
        <description>HelloWorld Portlet using Spring MVC</description>
        <portlet-name>HelloSpringPortletMVC</portlet-name>
<display-name>Hello World Spring Portlet MVC Framework Portlet</display-name>
        <portlet-class>         org.springframework.web.portlet.DispatcherPortlet
</portlet-class>
        <supports>
                <mime-type>text/html</mime-type>
                <portlet-mode>VIEW</portlet-mode>
        </supports>

        <supported-locale>en</supported-locale>
        <portlet-info>
<title>
Hello World Spring Portlet MVC Framework Portlet
</title>
                <short-title>
HelloWorldSpringPortletMVC 
                </short-title>
                <keywords>
spring portlet
</keywords>
        </portlet-info> 
</portlet>
</portlet-app>

DispatcherPortlet chịu trách nhiệm điều khiển request từ người dùng. Khi nhận được một request, nó sẽ tìm Controller chịu trách nhiệm xử lý cho request này, sau đó gọi handleActionRequest() hay handleRenderRequest() tùy thuộc vào kiểu sử lý của request. Controller class thi hành phần business logic và trả lại một View để trả kết quả xử lý cho người dùng.

Như đã thấy, DispatcherPortlet là trung tâm xử lý trong Spring Portlet MVC Framework. Ngoài ra, DispatcherPortlet còn chịu trách nhiệm loading application context (file cấu hình của Spring). Đầu tiên, kiểm tra giá trị của configLocation. Nếu không được khai báo, nó sẽ đặt giá trị mặc định là <portlet-name>-portlet.xml, và tìm trong thư mục /WEB-INF. Trong file portlet.xml, chúng ta không khai báo configLocation, vậy ta cần tạo file HelloWorldPortletMVC-portlet.xml.

HelloSpringPortletMVC-portlet.xml

Tạo file HelloSpringPortletMVC-portlet.xml trong webapp/WEB-INF như sau:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 
\"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<bean id="viewController" 
class="com.bds.example.springmvc.ViewController"></bean>
        <bean id="portletModeHandlerMapping" class=
"org.springframework.web.portlet.handler.PortletModeHandlerMapping">
            <property name="portletModeMap">
                <map>
                    <entry key="view">
                        <ref bean="viewController"/>
                    </entry>
                </map>
            </property>
     </bean>
</beans>

Đây là file cấu hình của portlet HelloSpringPortletMVC. Có 2 beans được định nghĩa:

viewController. Chỉ đến class com.bds.example.springmvc.ViewController.java.
portletModeHandlerMapping. Như ta đã biết, khi DispatcherPortlet nhận được một request, nó sẽ tìm Controller thích hợp để điều khiển request đó. PortletModeHandlerMapping là nơi điều khiển view.

PortletModeHandlerMapping là một class đơn giản hiện thực từ interface HandlerMapping và được DispatcherPortlet dùng để tìm Controller thích hợp cho mọi request. Class PortletModeHandlerMapping dùng mode của Portlet để tìm Controller.

ViewController.java

Ta biết rằng viewController bean sẽ xử lý tất cả View mode requests. Bước tiếp theo là tạo ViewController.java như sau:

package com.bds.example.springmvc;

import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import org.springframework.web.portlet.ModelAndView;
import org.springframework.web.portlet.mvc.AbstractController;

public class ViewController extends AbstractController{
        protected ModelAndView handleRenderRequestInternal(RenderRequest request, 
        RenderResponse response) throws Exception {
                ModelAndView modelAndView = new ModelAndView("View");
                return modelAndView;
        }
}

Chú ý: Nếu bạn đã từng dùng Struts Framework, thì Controller class cũng giống như một Action class trong Struts.
Mọi controller class trong Spring Portlet MVC Framework phải trực tiếp hoặc gián tiếp implement interface org.springframework.web. portlet.mvc.Controller. Để đơn giản hơn, Spring Framework cung cấp AbstractController, và một số extends phục vụ một số action cơ bản. Ta cũng có thể tự implement Controller class, nhưng phải quan tâm đến một số vấn đề như: reuse, thread-safe, và khả năng điều khiển nhiều requests trong suốt vòng đời của portlet.
Trong code trên, tôi tạo ViewController class bằng cách extend từ AbstractController. Vì ta chỉ cần xử lý cho mode view, nên ta chỉ cần override phương thức handleRenderRequest() từ AbstractController. Với controller trên, HelloWorldPortletMVC sẽ chỉ render trang View.jsp đến người dùng khi người dùng truy cập đến portlet này.

web.xml

Theo Portlet Specification 1.0, mọi ứng dụng portlet sẽ theo chuẩn của Servlet Specification 2.3, và cần một file miêu tả cho deployment(web.xml). Tạo web.xml trong thư mục /WEB-INF/ như sau:

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation=
"http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
        <display-name>
Hello Spring Portlet MVC Framework Application
</display-name>
        <servlet>
                <servlet-name>ViewRendererServlet</servlet-name>
                <servlet-class>
                        org.springframework.web.servlet.ViewRendererServlet
                </servlet-class>
        </servlet>
        <servlet-mapping>
                <servlet-name>ViewRendererServlet</servlet-name>
                <url-pattern>/WEB-INF/servlet/view</url-pattern>
        </servlet-mapping>
        <listener>
                <listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
        </listener>
</web-app>

File web.xml khai báo 2 việc:

ViewRendererServlet. ViewRendererServlet là một cầu nối thể hiện servlet cho portlet. Trong quá trình render, DispatcherPortlet đặt PortletRequest trong ServletRequest và chuyển điều khiển cho ViewRendererServlet để render. Bước này cho phép Spring Portlet MVC Framework dùng lại các thành phần View như trong phiên bản cho servlet, là Spring Web MVC Framework.

ContextLoaderListener. ContextLoaderListener chịu trách nhiệm phần load file cấu hình Web Application context tại thời điểm ứng dụng bắt đầu chạy. Web application context được chia sẻ cho tất cả các portlet trong cùng ứng dụng portlet. Trường hợp có 1 bean được định nghĩa 2 lần, bean được định nghĩa trong portlet application context được ưu tiên hơn trong Web application context.

ContextLoader đọc giá trị của contextConfigLocation. Nếu contextConfigLocation không được khai báo, sẽ dùng giá trị mặc định là /WEB-INF/applicationContext.xml.

applicationContext.xml

Như đã nói ở trên, nếu giá trị của contextConfigLocation không được khai báo, ViewRendererServlet sẽ lấy giá trị mặc định là /WEB-INF/applicationContext.xml file. Tạo applicationContext.xml có nội dung sau:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<bean id="viewResolver" class=
"org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass">
<value>
org.springframework.web.servlet.view.JstlView
</value>
</property>
<property name="prefix">
<value>/WEB-INF/jsp/</value>
</property>
<property name="suffix">
<value>.jsp</value>
</property>
</bean>
</beans>

Trong code trên, file applicationContext.xml định nghĩa 1 bean là viewResolver. viewResolver được dùng để khai báo nơi chứa các file JSP.
Ta khai báo 2 giá trị cho viewResolver bean:

Prefix – thư mục chứ file jsp /WEB-INF/jsp/

Suffix – đuôi của file phải là JSP

Lấy một ví dụ, khi đối tượng ModelAndView trả về với giá trị là View thì file được view ra là /WEB-INF/jsp/View.jsp.
Và cuối cùng, tạo một file View.jsp đơn giản với thông điệp "Hello from Spring Portlet MVC Framework" trong thư mục /WEB-INF/jsp.

Đọc tiếp >>