PHP Test tools: How to use SimpleTest in Eclipse (part 1)

Cài đặt SimpleTest trong Eclipse

  • Cài đặt từ Remote Site

  • Cài đặt từ Local Site

Cấu hình SimpleTest trong Eclipse

  1. Chọn Window > Preferences… trên menu bar
  2. Chọn “Simple Test” trong danh mục liệt kê bên tay trái.
  3. Nhập hoặc chọn đường dẫn tới file php.exe
  4. Nhập định dạng file cho file dùng để test. Ví dụ “.php” hooặc “.test.php”.
  5. Click OK.

Sử dụng SimpleTest trong Eclipse

  • Tạo mới một PHP Project với tên là Test gồm các thư mục con:
    • Test\classes: dùng chứa các class cần test.
    • Test\test: chứa các file test.
  • Tạo files Calculator.php trong thư mục ‘classes’.
<?php
class Calculator{
  function add($x, $y){
    return $x + $y;
  }

  function subtract($x, $y){
    return $x - $y + 1; // Hiện thực sai
  }
}
?>
  • Tạo file testCalculator.php trong thư mục ‘test’.
<?php
require_once(dirname(__FILE__). '/../classes/Calculator.php');
class testCalculator extends UnitTestCase {
	function test_exists(){
		$url = dirname(__FILE__);
		$this->assertTrue(file_exists($url . '/../classes/Calculator.php'),"File not existed at $url");
	}

	function test_add(){
		$cal = new Calculator();
		$result = $cal->add(1,2);
		$this->assertEqual(3, $result, "Passed");

	}

	function test_subtract(){
		$cal = new Calculator();
		$result = $cal->subtract(1,2);
               $this->assertEqual(-1, $result, " Value what we expected is '-1' is not equal '$result' which is returned from subtract function");
	}

}
?>
  • Chọn Run As > Simple Test (hoặc tổ hợp phí Alt+Shift+X, G). Hộp thoại kết quả sẽ xuất hiện như sau:
Failed Testing

Failed Testing

  • Cửa sổ kết quả cho thấy phần hiện thực hàm “subtract” của lớp Calculator đã hiện thực sai. Sửa lại file Calculator.php như sau:
<?php
class Calculator{
  function add($x, $y){
    return $x + $y;
  }

  function subtract($x, $y){
    return $x - $y + 1; // Hiện thực sai
    return $x - $y;
  }
}
?>
  • Chọn Run As > Simple Test, kết quả như sau:
Passed Testing

Passed Testing

Một số lưu ý:

  • Không có yêu cầu cụ thể đối với việc đặt tên file dùng để test (nhưng nên theo chuẩn).
  • Tên function trong file test (cụ thể là testCalculator.php) phải bắt đầu bằng tiền tố “test” (không phân biệt chữ viết hoa hay chữ viết thường).
  • Có thể test trực tiếp qua browser, khi đó:
    • Download và giải nén gói simpletest ở trang http://simpletest.org/en/download.html
    • Chép thư mục simpletest vào trong thư mục Test/test/ chung với file testCalculator.
    • Thêm dòng lệnh sau vào đầu file testCalculator.php:
          require_once(dirname(__FILE__) . '/simpletest/autorun.php');
    • Mở browser (IE, Firefox, Safari…) gõ vào url  sau đây, trường hợp của mình file testCalculator nằm trong thư mục /demo/Test/test/:
          http://localhost/demo/test/test/testCalculator.php
    • Kết quả sẽ như sau:

    Passed Testing in Safari Browser

    Passed Testing in Safari Browser

Resource:

  • http://simpletest.org/eclipse/readme.html

PHP test tools: SimpleTest or PHPUnit

Trang opensourcetesting.org giới thiệu 9 công cụ hỗ trợ tiến trình Unit Test đối với lập trình PHP gồm có:

  • Amock
  • izh_test
  • PHP Assertion Unit Framework
  • PHPUnit (dựa trên nền tảng JUnit)
  • PHPUnit (trong gói PEAR)
  • Simple Test
  • Spike PHPCheckstyle
  • Spike PHPCoverage
  • Testilence.

Tuy nhiên, căn cứ vào số lượng download, có thể thấy nổi bật lên trong số đó chính là Simple Test (>100k lượt) và PHPUnit (>35k lượt).

Simple Test chủ yếu được phát triển bởi Marcus Barker và một số thành viên khác trong khi đó PHPUnit được phát triển bởi  Sebastian Bermann dựa trên nền tảng của JUnit nên có vẻ phát triển ổn định và được hỗ trợ bởi một cộng đồng lớn hơn so với Simple Test. Điều này thể hiện qua việc việc PHPUnit đã đưa ra phiên bản 4.0 so với phiên bản 1.0.1 của Simple Test.

Vậy chúng ta cần gì ở một PHP test tools:

  • Hỗ trợ mô hình test tăng dần, cho phép tạo các test case trước khi triển khai.
  • Hỗ trợ quá trình test qua browser hoặc command-line.
  • Có thể thực hiện cả việc test độc lập, theo nhóm và các bài test tổng thể
  • Có thể customize phần hiển thị kết quả.
  • Cho phép kiểm tra cấu trúc của lớp.
  • Kiểm tra các biệt lệ và sự kiểm soát biệt lệ.
  • Cung cấp các plug-in để tích hợp với IDE

May thay, cả SimpleTest và PHPUnit đều đáp ứng được hầu hết những yêu cầu đó. Tuy nhiên, mỗi công cụ cũng có những ưu và nhược điểm riêng:

Về phía PHPUnit.

  • Ưu điểm:
    • Được sử dụng và hỗ trợ rộng rãi từ cộng đồng  Zend: Cập nhật thường xuyên, mức độ lỗi ít, tài liệu chi tiết.
    • Có thể tạo nhiều loại report khác nhau.
  • Khuyết điểm:
    • Mock Objects được đưa ra trong phiên bản PHPUnit 3 song vẫn chưa thể sánh bằng SimpleTest
    • Không thực thi trực tiếp từ browser.
    • Ít chức năng hơn Simple Test

Về phía SimpleTest.

  • Ưu điểm:
    • Hỗ trợ Mock Objects mạnh mẽ
    • Hoạt động chung với PHPUnit
    • Có thể thực thi trực tiếp từ browser lẫn command-line.
    • Có thể test cả hành vi lẫn trạng thái của đối tượng.
    • Người dùng  Drupal có thể cài đạt module để sử dụng SimpleTest
  • Khuyết điểm:
    • Phần tài liệu không bằng PHPUnit
    • Cần thêm sự bổ sung mở rộng để dùng chung với Zend Framework

Mock Objects mô phỏng lại các đối tượng thực sự trong ứng dụng, chúng cũng có các phương thức giống như các đối tượng mà nó mô phỏng, chính vì vậy nó thường được tạo ra nhằm kiểm tra tính đúng đắn của một đối tượng phụ thuộc vào đối tượng mà nó mô phỏng.

Như chúng ta đã biết, trong các ứng dụng, một đối tượng thường phụ thuộc vào sự tồn tại của một (hay nhiều) đối tượng khác, chính vì vậy sẽ gây ra trở ngại khi phải thực hiện công đoạn Unit Test (mục đích là cách ly các thành phần của ứng dụng).

Giả sử có class StudentBSO cung cấp các business services cho các đối tượng Student và sử dụng StudentDAO để lưu dữ liệu vào database. Khi muốn test class StudentBSO, chúng ta chỉ cần gọi đối tượng mock object mô phỏng đối tượng StudentDAO, thực hiện triệu gọi các phương thức với các đối số tương ứng (đã được xác định) nhằm đạt được kết quả mong muốn thay vì phải gọi trực tiếp tới đối tượng StudentDAO.

Về mặt tính năng, giữa chúng có nhiều tính năng tương đồng và dễ dàng tích hợp với người dùng Eclipse. Nếu như trước đây người dùng PHPUnit cảm thấy yếu thế hơn khi mà PHPUnit không hỗ trợ Mock Object thì giờ đây, từ phiên bản 3 đã hỗ trợ Mock Object (tuy vẫn còn rất hạn chế) và nhiều tính năng khác như Database Testing… Tuy nhiên, người dùng SimpleTest có thể thực sự thấy quá trình Test thực sự “Simple” bởi những tính năng mà nó đem lại.

Resource:

7 lưu ý khi thiết kế web với CSS và HTML!

  1. Không sử dụng các thẻ HTML nhằm mục đích định dạng hay trình bày nội dung. Hãy nhớ rằng, các thẻ HTML chỉ phục vụ cho việc đánh dấu tài liệu, còn các thuộc tính của CSS mới được dùng cho việc định dạng nội dung.
  2. Không chèn các đoạn mã css vào bên trong tài liệu HTML. Để thực hiện công việc này hãy sử dụng các class.
  3. Hãy định nghĩa các đặc tính định dạng thường dùng một lần duy nhất.
  4. Bạn hoàn toàn có thể áp dụng nhiều class cho một một HTML element.
  5. Sử dụng selector hierarchical thay cho việc mở rộng thêm các class.
  6. Hãy Sử dụng external style sheet. Chỉ sử dụng internal style sheet trong trường hợp bạn muốn có những ngoại lệ riêng cho một trang HTML nào đó.
  7. Nếu cần, hãy chia nhỏ file .css thành nhiều file tùy theo ý đồ thiết kế hoặc thói quen, miễn là hợp lý và logic.

Web Standards

Hôm nay trong lớp lại nghe tới chuyện việc hiển thị web ở mỗi trình duyệt mỗi khác, IE khác, Firefox khác, Safari lại càng khác… mình lại nghĩ tới Web Standards. Cũng chẳng mới mẻ gì, khái niệm này mình cũng nghe lâu rồi, và cũng cố gắng áp dụng, à không tuân thủ mỗi khi “làm web” – dùng từ “làm” thay cho “design” bởi lẽ mình thấy những gì mình làm ra chưa thể gọi là “nghệ thuật”, mà không phải là “nghệ thuật” – sao có thể gọi là design.

Web Standards

Dù bạn đã từng làm công việc phát triển một ứng dụng web hay chỉ là những người mới tiếp cận công việc đầy thú vị này, thì Web Standard vẫn thật sự là một vấn đề bạn cần lưu tâm. Nó sẽ giúp bạn có được một “ấn phẩm web” có “chất lượng”, hoạt động ổn định trên hầu hết các trình duyệt web thông dụng, bạn sẽ không còn lo lắng quá nhiều về vấn đề người dùng sẽ dùng trình duyệt nào, hệ điều hành nào…. để sử dụng ứng dụng web mà bạn đã tạo ra. Thông thường thì việc phát triển các ứng dụng web “tương thích” với nhiều trình duyệt… sẽ phát sinh thêm những dòng code để phát hiện người dùng đang sử dụng trình duyệt nào và ứng với mỗi trình duyệt như thế sẽ có những xử lý khác nhau, tăng số lượng dòng code đồng nghĩa với chi phí phải trả cho nhân viên sẽ cao hơn. Tuy nhiên, do vấn đề lợi nhuận nên công việc đó thường bị xem nhẹ, thậm chí bỏ đi. Hậu quả là một phần nội dung hoặc những thao tác như ý đồ thiết kế không được thực hiện. Chính vì vậy, việc tuân thủ Web Standard sẽ góp phần giảm thiểu chi phí cho việc phát triển một cách đáng kể. Thậm chí ứng dụng web của bạn còn có khả năng phục vụ cho nhiều đối tượng người dùng, đặc biệt là dành cho cả người khiếm thị.

Vậy thực chất Web Standards là gì? Web Standards là một tập hợp các tiêu chuẩn, chuẩn mực về công nghệ, ngôn ngữ… đảm bảo cho một trang web có thể hoạt động tốt trên mọi nền tảng phần mềm hay phần cứng. Không những vậy, nó còn hạn chế được chi phí phát sinh khi tiến hành phát triển, bảo trì trang web.

Vậy tuân thủ Web Standards sẽ đem lại lợi ích gì?

  • Trước mắt là vấn đề hiển thị. Mọi thứ sẽ tương đương nhau cho dù bạn dùng trình duyệt nào, hệ điều hành nào, trên PC, thiết bị PDA hay các điện thoại có chức năng duyệt web và thậm chí cả công tác in ấn nữa.
  • Tiếp theo dĩ nhiên là vấn đề lợi nhuận như đã phân tích ở trên.
  • Giải quyết được vấn đề cộng tác, bạn hình dung một ứng dụng web được phát triển bởi nhiều cá nhân có trình độ, tư duy, phương pháp tiếp cận khác nhau… chưa kể, công việc được chia thành nhiều công đoạn, quy trình phát triển khác nhau… do đó cần phải tạo ra những quy ước để các cá nhân có thể hợp tác “ổn thỏa” với nhau. Do đó, tốt nhất là sử dụng chuẩn
  • Một điều nữa đó là nó hứa hẹn ứng dụng web sẽ được thực thi nhanh hơn (dù chưa được kiểm chứng rõ ràng). Lý do có thể là do số lượng dòng code được giảm thiểu, trình duyệt không còn phải xử lý những đoạn code lạ do các kỹ thuật hack (như hack css) gây ra.

Tuân thủ Web Standards như thế nào? Đây thực sự là một câu hỏi hay! Trước khi nói về cách thức tuân thủ Web Standards chúng ta cần biết rằng, khi nói tới “Standard” là nói tới các ngôn ngữ được sử dụng trong Web Standards. Cụ thể là

  • Ngôn ngữ có cấu trúc và mang tính ngữ nghĩa (Structural and Semantic Languages): Đó chính là HTML 4.01, XHTML 1.0 và XML 1.0
  • Ngôn ngữ trình bày (Presentation Languages): Đó chính là CSS level 1, 2, 2. Ngôn ngữ này giúp chúng ta có thể dễ dàng và linh động trong việc định dạng màu sắc, kích thước, vị trí… của các thành phần trong ứng dụng web của bạn.
  • Mô hình đối tượng (Object Model): Đó là DOM level 1, 2, 3. Mô hình này cho phép chúng ta thao tác được với tất cả các đối tượng theo mô hình cây.
  • Ngôn ngữ kịch bản (Scripting Language): Đó chính là ECMAScript được biết với cái tên thông dụng là JavaScript dù rằng gọi như thế là không đầy đủ. Loại ngôn ngữ này thường được biết đến với việc tạo ra các hiệu ứng, các xử lý hoạt động tương tác ở phía client.
  • Ở một mức cao hơn, bạn nên biết đến phiên bản mở rộng của HTML và XHTML, các ngôn ngữ đánh dấu mở rộng như MathML. Tuy nhiên, tạm thời chúng ta chỉ cần quan tâm tới 4 loại ngôn ngữ ở trên là đủ.

Vậy là bạn đã đoán được ý đồ của việc tuân thủ Web Standards rồi đấy! Chỉ cần bạn sử dụng các ngôn ngữ trên cho các ứng dụng web của bạn một cách thành thục và cố gắng phát huy tối đa lợi thế mà mỗi ngôn ngữ trên đem lại. Tuy nhiên cần chú ý tới những yêu cầu đi kèm đối với việc sử dụng mỗi ngôn ngữ. Chẳng hạn như các quy định khi làm việc với XHTML đó là:

  • Có thẻ mở thì phải có thẻ đóng. Ví dụ: <html>…</html>
  • Đối với các loại thẻ rỗng (empty tags) như <br>, <hr>… được sử dụng dưới hình thức <br />, <hr /> hoặc có thẻ đóng </br>, </hr>..
  • Các giá trị của các thuộc tính phải được bao bởi cặp dấu nháy đơn hoặc nháy kép.
  • Thẻ mở trước phải được đóng sau. Tức là các thẻ có thể được lồng vào nhau nhưng không được chồng lên nhau. Ví dụ: <b><i>Hello World!</b></i> là không hợp lý. Phải là: <b><i>Hello World!</i></b>

Bạn đã phần nào thấy được sự tuyệt vời mà Web Standards đem lại, việc tuân thủ chúng có vẻ cũng đơn giản. Tuy nhiên, cũng như bất kỳ những vấn đề gì, việc tuân thủ Web Standards cũng có những mặt hạn chế và bất cập.

  • Đầu tiên, bạn sẽ phải thay đổi tư duy khi phát triển ứng dụng web. Một điều thường thấy là các trang web vẫn được thiết kế theo hướng table, nghĩa là bạn sử dụng table để trình bày bố cục (layout) của trang web. Tức là phần code HTML của trang web thường có dạng <body><table width=”100%”>…</table></body>… hoặc tương tự như thế. Cách thiết kế này gọi là “table-based”. Để thay thế nó, bạn nên biết và sử dụng cách thiết kế “boxed-model” mà bạn có thể tìm thấy nó trong bất cứ tài liệu nào về CSS. Còn vấn đề tại sao ư, việc layout cho trang web của bạn theo hướng table-based sẽ khiến trang web của bạn load chậm hơn, nó làm cho trang web của bạn mất đi tính “accessible”, tức là bạn không thể lướt web bằng bàn phím hoặc trên các thiết bị PDA, điện thoại chưa kể, bạn không thể tận dụng tối đa những điều tuyệt vời mà CSS đem lại, mà trong chừng mực của bài viết này không thể trình bày kỹ càng. Một cách đơn giản, hãy sử chúng vì nó là “chuẩn”.
  • Bạn phải học cách phân tách công việc trình bày và xử lý. Một cách nôm na đó là khi bạn muốn thay đổi định dạng màu sắc, kích thước của một phần tử, việc mà bạn cần làm đó là chỉnh sửa file CSS chứ không phải là chỉnh sửa các đoạn code xử lý.
  • Một bất lợi nữa đó là hiện nay các trình duyệt vẫn chưa có sự “ăn ý” với nhau. Giữa chúng vẫn còn một khoảng cách nhất định. Bạn hoàn toàn có thể nhận ra điều này khi ứng dụng boxed-model trên các trình duyệt IE và đem so sánh với Firefox, Nescape, Opera, Safari… Bạn sẽ nhận thấy rằng, chính IE mới là kẻ “tội đồ”. Vì vậy hãy sử dụng song song các trình duyệt.
  • Đó là chưa kể tới việc bạn phải tốn công nghiên cứu Web Standard là cái gì nữa đó! Nhưng đừng quá lo lắng, mọi thứ khi mới bắt đầu đều gặp khó khăn cả. Dần dần, bạn sẽ thấy những điều tuyệt vời mà Web Standards đem lại.

Bạn đã từng quan tâm tới chất lượng sản phẩm liệu có đáp ứng được yêu cầu của bạn như hứa hẹn của nhà sản xuất, bạn đã từng quan tâm tới ISO của một sản phẩm, của một công ty, của một tổ chức; đã từng nghe tới CMMi của một công ty phần mềm… vậy hãy quan tâm tới Web Standard.

Describing Web Resource in RDF (Chapter III – Part II)

Tiếp theo loạt bài về Semantic Web, chúng ta sẽ tìm hiều một số khái niệm liên quan được dùng trong RDF.

  • Tài nguyên (resource): Chúng ta có thể hiểu đơn giản rằng một tài nguyên cũng giống như một đối tượng, một vật mà chúng ta muốn đề cập. Tài nguyên có thể là tác giả, quyển sách, nhà xuất bản, nơi chốn, con người, khách sạn, các câu truy vấn tìm kiếm v.v… Mỗi tài nguyên có một URI (Universal Resource Indentifier). Một URI có thể là một URL (Unified Resource Locator) hoặc một loại giá trị định danh duy nhất nào đó. Lưu ý rằng, một định danh không nhất thiết phải cho phép truy cập tới tài nguyên. URI đã được định nghĩa không chỉ cho địa chỉ web mà còn cho các đối tượng khác số điện thoại, số ISBN hay các vị trí địa lý. Thậm chí đã có nhiều cuộc tranh luận về bản chất của URI cả về phương diện triết học, chẳng hạn như cái gì “định danh duy nhất” một con người…, trong khuôn khổ của bài viết, chúng ta chỉ giả định rằng URI định danh một tài nguyên web.
  • Thuộc tính (Property): Thuộc tính là loại tài nguyên; chúng mô tả mối quan hệ giữa các tài nguyên, chẳng hạn như “written by”, “age”… Thuộc tính trong RDF cũng được xác định bởi URI (thường là URL). Ý tưởng dùng URI để xác định một vật và mối quan hệ giữa chúng là khá quan trọng. Nó cho phép chúng ta có cùng một mô hình đặt tên, do đó, giảm thiểu được những tình huống trùng tên vốn gây ra nhiều phiền toái đối với việc biểu diễn dữ liệu.
  • Phát biểu (Statement): Một phát biểu xác định thuộc tính cho tài nguyên. Một phát biểu là một bộ ba object-attribute-value gồm có một tài nguyên, một thuộc tính và một giá trị. Giá trị có thể là tài nguyên hoặc cũng có thể là giá trị kiểu chuỗi.
  • Biểu diễn một phát biểu: Giả sử, ta có một phát biểu sau:
  • David Billington is the owner of the Web page http://www.cit.gu.edu.au/~db

    Cách đơn giản để thể hiện phát biểu này đó là sử dụng định nghĩa về bộ ba object-attribute-value ở trên(”David Billington”, http://www.mydomain.org/site-owner, http://www.cit.gu.edu.au/~db)Chúng ta có thể xem bộ ba (x, P, y) như là một biểu thức logic P(x,y), trong đó mệnh đề P chỉ ra mối quan hệ giữa x và y. Thực ra RDF chỉ đưa ra mệnh đề.

    Figure 3-1

    Hình 3.1: Đồ thị biểu diễn bộ ba Để ý rằng thuộc tính “site-owner” và một trong hai đối tượng được xác định bởi URL, đối tượng còn lại được xác định bởi một chuỗi ký tự.Hình 3.1 biểu diễn đồ thị của phát biểu đã đưa ra. Nó là một đồ thị có hướng với các node có gắn nhãn và các cung; các cung được nối trực tiếp từ tài nguyên (chủ từ – subject trong phát biểu) tới giá trị (túc từ – object trong phát biểu). Trong Trí tuệ nhân tạo, loại đồ thị này được gọi là mạng ngữ nghĩa (semantic net). Như đã nói, giá trị được nêu ra trong một phát biểu có thể là một tài nguyên. Do đó, nó có thể được liên kết tới một tài nguyên khác như trong các triple sau:

    • (http://www.cit.gu.edu.au/~db, http://www.mydomain.org/site-owner, “David Billington”)
    • (”David Bilington”, http://www.mydomain.org/phone, “3875507″)
    • (”David Billington”, “http://www.mydomain.org/uses, http://www.cit.gu.edu.au/~arock/defeasible/Defeasible.cgi)
    • (”www.cit.gu.edu.au/~arock/defeasible/Defeasible.cgi”, http://www.mydomain.org/site-owner,”Andrew Roc”
Những triple đó được biểu diễn như sau
Figure 3-2

Đồ thị thật sự là công cụ mạnh mẽ để mô tả cho con người hiểu, nhưng mục đích của Semantic Web lại yêu cầu những hình thức biểu diễn mà máy tính có thể truy xuất và xử lý được.Do đó, có một hình thức biểu diễn đáp ứng được yêu cầu đó là dựa vào XML. Theo khả năng này, một tài liệu RDF được biểu diễn bởi một element của XML với thẻ là rdf:RDF. Phần nội dung của element này đó là số lượng các Diễn giải (Descriptions) dùng thẻ rdf:Description. Mỗi diễn giải như thế tạo nên một phát biểu về một tài nguyên, được xác định bằng một trong ba cách sau:

    • Thuộc tính about: tham chiếu tới một tài nguyên đã có
    • Thuộc tính ID : tạo ra một tài nguyên mới
    • Không có tên: tạo ra một tài nguyên nặc danh (anonymous )

Sau đây là ví dụ về cách thể hiện phát biểu đã đưa ra

Figure 3-3

Thành phần rdf:Description tạo ra một phát biểu về tài nguyên “http://www.cit.gu.edu.au/~db”. Trong đó, phần thuộc tính đóng vai trò như một thẻ, và phần nội dung là giá trị của thuộc tính đó. Việc mô tả đó tuân theo đúng một trật tự, nói cách khác cú pháp XML thiết lập một sự tuần tự (serialization). Thứ tự của các diễn giải (hay tài nguyên) thì không quan trọng mà tùy theo mô hình trừu tượng của RDF. Điều này một lần nữa cho thấy rằng, mô hình đồ thị là mô hình dữ liệu thực sự của RDF còn XML chỉ là hình thức biểu diễn cho đồ thị mà thôi.