2012-05-18 20 views
7

Pracuję nad nowym projektem, w którym chcę wyświetlić niektóre dane na ekranie. Postanowiłem użyć TDD, który jest dla mnie nowy, ale uwielbiam ten pomysł i do tej pory się dogaduję.Jak TDD JFrame?

Ustawiłem JFrame, dodałem Textarea i umieściłem tam tekst, ale jak mogę to właściwie przetestować? Czy to złe myślenie w kontekście TDD po ​​mojej stronie? Chcę mieć pewność (w trybie TDD), że dane zostaną poprawnie wyświetlone! Utworzony tekst jest dobrze pokryty testami, ale wyświetla się w postaci innej niż .

Oto całkowicie uproszczony przykład:

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

Czy na pewno chcesz dołączyć testowanie granic ("urządzenie" testujące interfejs użytkownika) do cyklu życia TDD? Jestem zwolennikiem TDD, ale nie obejmuję testów brzegowych, tylko warstwy usług i innych części warstwy biznesowej. –

+0

Baastian, to świetne pierwsze pytanie. +1. Dzięki za wkładanie w to wysiłku. – jmort253

+0

Czy przetestowanie wyświetlania i innych rzeczy powinno być postrzegane jako zupełnie inny temat? Jak już wspomniałem, jestem całkiem nowy dla TDD ... –

Odpowiedz

5

TDD wymaga, aby myśleć o rzeczach trochę inaczej. Najpierw określasz, co masz zamiar przetestować, i jak zamierzasz przetestować to zanim faktycznie napiszesz jakiś kod do rozwiązania.

Dla GUI może to być dość trudne i, szczerze mówiąc, twój GUI nigdy nie powinien zawierać żadnej logiki, która mogłaby znajdować się w osobnej warstwie. Na przykład wyświetlana wartość powinna pochodzić z obiektu, który nie ma nic wspólnego z interfejsem GUI, ale można to sprawdzić indywidualnie. Pozwala to na opracowanie głównej logiki biznesowej (model i kontroler) oddzielonej od wyświetlacza (widok). To jest wzór MVC. Testowanie rozwoju opartego na testowaniu oznacza po prostu, że przed napisaniem kodu możesz sprawdzić, co możesz, a kiedy dodasz więcej kodu, zacznie upływać więcej testów.

Wolę skupić się na moim projekcie i upewnić się, że wszystko, co generuje wartość tekstową, działa zgodnie z oczekiwaniami. Interfejs GUI powinien być "głupi" i skupiać się wyłącznie na wyświetlaniu lub pobieraniu wartości, z niewielką, jeśli jakąkolwiek obawą, jeśli wyświetlane wartości są rzeczywiście poprawne.

Ponieważ GUI jest bardzo trudne do przetestowania za pomocą automatycznych narzędzi (poprawnie przetestuj), uniknęłbym tego tak bardzo, jak to możliwe, i odłączyłem mój GUI od mojej aktualnej aplikacji tak bardzo, jak tylko potrafię. Następnie możesz przetestować GUI raz, aby upewnić się, że wyświetla to, co powinien, i skupić się na logice biznesowej bez konieczności ciągłego testowania GUI, ponieważ nie dotykasz tego kodu.

+0

Oddzielę GUI tak mocno, jak to tylko możliwe i na razie opuścimy to z mojego cyklu TDD! Thx –

+0

Doskonały wybór. Twój interfejs GUI nigdy nie powinien zawierać logiki, która może zakłócać działanie aplikacji. – Ewald