SWT Designer logo

SWT Designer (part of the WindowBuilder Pro suite) is the best two-way GUI visual editor for the SWT and RCP world. Instantiations provides free (as beer) licenses for Open Source projects and so, I’m pleased to announce (with a small delay though ;)) that they have provided us (me) with such a license for using it in eConference NG software.

Additionally, we also have a license for WindowTester SWT so we can build tests for the GUI too, a feature that we’ll make our future eConference team members really happy 🙂

So, time to start codin … ehm, designing user interfaces 🙂

SWT Designer
CondividiShare on FacebookTweet about this on TwitterShare on Google+Pin on PinterestEmail this to someone

7 thoughts on “SWT Designer

  • 23 May 2007 at 22:32
    Permalink

    Ho più di un commento. Il primo: complimenti per l’inglese.

    Reply
  • 23 May 2007 at 22:34
    Permalink

    Secondo: credi che testare la GUI sia più facile di testare gli strati sottostanti con JUnit?

    Reply
  • 23 May 2007 at 23:23
    Permalink

    Il testing della GUI è un mio pallino da quando mi occupavo di fare i test di accettazione sulle applicazioni web: lì era molto più facile in quanto alla fine il test simulava un browser (clicca su questo link, verifica che la pagina si chiami cosi’, che la tabella abbia X righe, …). Con le applicazioni desktop invece questo non è più fattibile a meno di non utilizzare macro-recorder (l’approccio utilizzato da praticamente tutti i tool di UI testing): Swing da questo punto di vista è migliore perchè l’API permette di interrogare i componenti e provocare eventi (quindi chi scrive i test framework è facilitato: SWT invece non permette affatto questo approccio).

    Quello che alla fine facevo (ma ho visto che lo fanno anche altri ;)) era spostare quanta più logica possibile fuori dalla UI in modo da poterla testare in maniera agnostica e rendere la GUI quanto “più stupida possibile” e che semplicemente passasse i valori al “blocco separato”. Però quando la GUI è complessa e i controlli interagiscono tra di loro diventa un casino ingestibile: praticamente ti trovi a ricreare uno specchio della GUI ma senza GUI, con tanto di eventi etc etc!.

    Alla fine la GUI la si prova “ad occhio” (“Bene, ora è scomparso il contatto andato offline”, “ora ha cambiato icona”, …) ed il “backend” con i test di unità.

    Ora mi aspetto di poter fare i test di accettazione con WindowTester e gli altri test come di norma: sono curioso di vedere se effettivamente è un approccio funzionante.

    Reply
  • 23 May 2007 at 23:33
    Permalink

    Ah, il commento è in inglese perchè Instantiations gradisce un pò di pubblicità 🙂 E non mi dispiace fargliene visto il prodotto.

    Reply
  • 24 May 2007 at 09:27
    Permalink

    aargh, un commento piu’ lungo del post :S
    mi annoiano
    riassumi 😉

    Reply
  • 24 May 2007 at 17:10
    Permalink

    Mario, hai mail letto questo breve articolo di Martin Fowler? http://www.martinfowler.com/ieeeSoftware/separation.pdf
    Parla proprio dell’importanza di separare il presentation code dal domain code. Tra i tanti vantaggi, c’è anche quello di poter fare a meno del GUI testing.
    Con gli strumenti di GUI testing, registrare gli eventi e salvarli come macro è facile. Modificare le macro, usando un qualche linguaggio di scripting spesso proprietario, è invece meno facile. Magari non è il caso di WindowTester SWT.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *