Pierced
I'm new here

Editor-Komponenten testen/mocken

Hallo,

aktuell versuche ich mich an der Modul-Entwicklung, um neue Editor-Komponenten zu erstellen oder bestehende zu erweitern.

Um den Entwicklungszyklus möglichst kurz zu halten, halte ich es für wichtig, dass man Editor-Komponenten mocken kann.

Ich stelle mir das in einer einfachen Form so vor:

JFrame frame     = new JFrame("Test");

    MyGuiEditor editor = new MyGuiEditor();
   
    // add the panel to this frame
    frame.add(editor.getEditorComponent());
    frame.setPreferredSize(new Dimension(800,700));
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);  
   
    // set Location
    frame.setLocationByPlatform(true);
    frame.pack();
    frame.setVisible(true);

Natürlich werden hier keine Testdaten berücksichtigt und automatisierte funktionale Tests sind dadurch auch nicht möglich.

Auf diese Weise könnte man jedoch sehr einfach prüfen, ob die GUI-Komponente vom Aussehen her in Ordnung ist.

Daher an dieser Stelle meine Frage:

Gibt es entsprechende Ansätze oder Mock-Objekte, gegen die man die Editor-Komponenten entwickeln kann?

Falls notwendig: An welcher Stelle müsste man eine Verbindung zum FS-Server durchreichen?

Vielen Dank

Georg

0 Kudos
5 Replies
Pierced
I'm new here

Hat niemand eine Idee?

Wie entwickelt ihr denn Eure Editoren/Anpassungen/Swing-Komponenten für gewöhnlich?

0 Kudos

Für einfache Szenarien ist eine simple main Methode in der jeweiligen Klasse sehr hilfreich. Man muss nur die Klasse neu kompilieren kann kann das Layout überprüfen.  Folgendes Beispiel stammt aus einer Klasse, die den Konfigurationsdialog für ein Modul beinhaltet.

/**
     * Main method for easier gui development.
     *
     * @param    args    unused.
     */
    public static void main(final String[] args) {
        final JFrame frame = new JFrame("Configuration");

        final WebAppConfiguration configurator = new WebAppConfiguration();
        final JComponent gui = configurator.getGui(frame);

        final JButton closeBtn = new JButton("Close");
        closeBtn.addActionListener(new ActionListener() {

            public void actionPerformed(final ActionEvent e) {
                frame.setVisible(false);
                frame.dispose();
            }
        });

        frame.getContentPane().add(gui);
        frame.getRootPane().setDefaultButton(closeBtn);
        frame.setSize(580, 300);
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);

        frame.setVisible(true);
    }

Bei entsprechender Trennung von Datenhaltung und GUI-Logik braucht man in der Regel gar keine FirstSpirit-Objekte um die GUI zu bauen. Man kann also in einem ersten Schritt die GUI per visuellem Editor ( z.B. den des Eclipse-Projektes) bauen und erst danach die Integration vornehmen.

0 Kudos

Danke für die Antwort!
Ich habe den Code gerade in mein Projekt eingefügt und habe nun das Problem, dass die Klasse WebAppConfiguration nicht gefunden wird. Im Classpath liegen fs-client.jar und fs-server.jar (aus Version 4.2.x)

Handelt es sich vielleicht um eine neuere Klasse oder um WebStartConfiguration?

0 Kudos

WebAppConfiguration ist eine selbst implementierte Klasse. Die getGui() Methode stellt die Swing-GUI zur Verfügung. Das Codebeispiel ist Teil  von javascript:;, wo Sie auch den kompletten Quellcode runterladen können.

0 Kudos

Ok,

so großartig unterscheidet sich das ja nun nicht von meinem Codebeispiel aus dem obigen Ansatz ;-), ich hatte mir erhofft, dass man geschickt Zugriff auf die FS-Laufzeitumgebung Zugriff bekommen kann.

Denn ich möchte ja auch Interaktionen testen können, die z.B. entstehen wenn ein Benutzer "save()" aufruft, ein Locking passiert usw.

Wenn ich es richtig sehe, gibt es dafür jedoch leider keinen vorgesehenen Weg.

Weitere Hinweise sind natürlich gern genommen 🙂

0 Kudos