2012-05-18 91 views
7

Tôi đang làm việc trên một dự án mới, nơi tôi muốn hiển thị một số dữ liệu trên màn hình. Tôi đặt bản thân mình để sử dụng TDD đó là mới cho tôi, nhưng tôi thích ý tưởng và nhận được cùng khá OK cho đến nay.Làm thế nào để TDD một JFrame?

Tôi thiết lập một JFrame, thêm một Textarea và đặt văn bản ở đó, nhưng làm thế nào tôi có thể kiểm tra đúng cách này? Hay là suy nghĩ sai lầm này trong bối cảnh TDD ở bên cạnh tôi? Tôi muốn chắc chắn (theo cách TDD), rằng dữ liệu được hiển thị chính xác! Việc tạo tạo của văn bản được hiển thị được bao phủ đúng cách với các thử nghiệm, nhưng hiển thị thì không.

Dưới đây là một ví dụ hoàn toàn đơn giản:

public class MyTextDisplay { 
    public static void main(String[] args) { 
     JFrame my_frame = new JFrame("DisplaySomeText"); 
     my_frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 

     JTextArea textArea = new JTextArea(5, 20); 
     textArea.setEditable(false); 

     my_frame.add(textArea); 
     my_frame.setVisible(true); 

     //this would be in a separate method 
     textArea.append("Hello World"); 
    } 
} 
+0

Bạn có chắc chắn muốn bao gồm thử nghiệm ranh giới ("đơn vị" kiểm tra giao diện người dùng) vào vòng đời TDD của bạn không? Tôi là một người đề xuất lớn của TDD, nhưng không bao gồm thử nghiệm ranh giới, chỉ là lớp dịch vụ và các phần khác của lớp nghiệp vụ. –

+0

Baastian, đây là một câu hỏi đầu tiên tuyệt vời. +1. Cảm ơn bạn đã nỗ lực vào nó. – jmort253

+0

Vì vậy, thử nghiệm hiển thị và các công cụ nên được xem như là một chủ đề hoàn toàn khác nhau? Như đã đề cập, tôi khá mới với TDD ... –

Trả lời

5

TDD đòi hỏi bạn phải suy nghĩ về những điều một chút khác nhau. Trước tiên, bạn xác định những gì bạn sẽ kiểm tra, và làm thế nào bạn sẽ kiểm tra nó trước khi bạn thực sự viết bất kỳ mã cho giải pháp.

Đối với GUI, điều này có thể trở nên khá phức tạp, và, trong tất cả sự trung thực, GUI của bạn sẽ không bao giờ chứa bất kỳ logic nào có thể nằm trong một lớp riêng biệt. Ví dụ, giá trị được hiển thị sẽ đến từ một đối tượng không có gì để làm với GUI, nhưng có thể được kiểm tra riêng lẻ. Điều đó cho phép bạn phát triển logic kinh doanh chính (mô hình và bộ điều khiển) tách biệt với màn hình (xem). Đây là mẫu MVC. Test Driven Development chỉ đơn giản có nghĩa là bạn kiểm tra những gì bạn có thể trước khi bạn viết mã, và, khi bạn thêm nhiều mã hơn, nhiều thử nghiệm sẽ bắt đầu vượt qua.

Tôi muốn tập trung vào thiết kế của mình và đảm bảo rằng mọi thứ đang tạo giá trị văn bản hoạt động như mong đợi. GUI sẽ là "câm" và chỉ tập trung vào hiển thị hoặc truy xuất các giá trị, với ít, nếu có bất kỳ mối quan tâm nào nếu các giá trị được hiển thị thực sự chính xác. Là một GUI nổi tiếng là khó kiểm tra với các công cụ tự động (kiểm tra chính xác), tôi tránh điều đó càng nhiều càng tốt và tách giao diện GUI khỏi ứng dụng thực tế của tôi càng nhiều càng tốt. Sau đó, bạn có thể kiểm tra GUI một lần, để đảm bảo nó hiển thị những gì nó được cho là, và tập trung vào logic nghiệp vụ mà không cần phải thực hiện các kiểm tra liên tục trên GUI khi bạn không chạm vào mã đó.

+0

Tôi sẽ tách giao diện đồ họa mạnh nhất có thể và để nó ra khỏi chu kỳ TDD của tôi ngay bây giờ! Thx –

+0

Lựa chọn tuyệt vời. GUI của bạn sẽ không bao giờ chứa logic có thể ảnh hưởng đến cách hoạt động của ứng dụng của bạn. – Ewald

Các vấn đề liên quan