Come fare in modo che il test Delphi DUnit fallisca quando TSQLConnection.Connected = true

Question

Quando si utilizza Delphi IDE, cambierà silenziosamente SQLConnection.Connesso a " true " quando si popolano gli elenchi di campi o tabelle in varie proprietà.

Dato che non voglio rilasciare con Connected = true, ho bisogno che il mio test dunit fallisca quando TSQLConnection.Connected viene lasciato vero in dfm.

Answer 1

Lo risolvo in un altro modo. Ho scritto una piccola utility che carica un file DFM e cerca proprietà che non dovrebbero essere presenti. Incluso il valore database.connected = true.

Questo può essere modificato per funzionare con qualsiasi proprietà appropriata. Ho inserito anche qui il nucleo del codice.

Per renderlo davvero utile, dovresti usare questa utility nel tuo script di build (io uso FinalBuilder). Il mio script inizia eseguendo il ciclo su file .dfm, eliminando una di queste proprietà, quindi compila ed esegue i test unitari. Se passano, continua a creare l'applicazione principale. Per me, questo è un modo migliore rispetto al fallimento di un test unitario, dal momento che puoi iniziare da un punto positivo noto garantito.

nState := 0;
bFound := False;
for nFileLoop := 0 to memoFile.Lines.Count - 1 do
begin
  szLine := memoFile.Lines[nFileLoop];

  case nState of      //
  0:
     begin
        if(0 <> Pos('TADOConnection', szLine)) then
        begin
           szSeeking := 'Connected';
           nState := 1;
        end
        else if(0 <> Pos('TADOTable', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end
        else if(0 <> Pos('TADOQuery', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end
        else if(0 <> Pos('TDBISAMTable', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end
        else if(0 <> Pos('TDBISAMDatabase', szLine)) then
        begin
           szSeeking := 'Connected';
           nState := 1;
        end
        else if(0 <> Pos('TDBISAMSession', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end
        else if(0 <> Pos('TDBISAMQuery', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end;
     end;
  1 :
     begin
        bFound := True;
        if(0 <> Pos('end', szLine)) then
        begin
           nState := 0;
        end
        else if(0 <> Pos(szSeeking, szLine)) then
        begin
           nPos := Pos('=', szLine);
           if nPos > 0 then
           begin
              memoFile.Lines[nFileLoop] := Copy(szLine, 1, nPos) + ' False';
           end;
        end;
     end;
  end;      // case
end;

Answer 2

GExperts ha un " Imposta proprietà componente " esperto che configuriamo per chiudere le connessioni al database su ogni compilazione. Da allora, non abbiamo avuto il problema.

Answer 3

È possibile scrivere il proprio discendente di TSQLConnection che non memorizza la proprietà Connected:

  TdzAdoConnection = class(TADOConnection)
  published
    property Connected stored false;
  end;

e usa quel componente anziché TSqlConnection.

(Quanto sopra è per TAdoConnection, ma anche TSQLConnection dovrebbe funzionare bene.)

Answer 4

OpenCTF - Component Test Framework per Delphi potrebbe essere interessante, crea automaticamente test unitari per le proprietà specificate di tutti i componenti in tutte le forme / moduli di dati. È open source e facile da usare.

" Guida introduttiva " documento: http://www.habarisoft.com/download/OpenCTFGettingStarted.pdf

  

Il framework di test dei componenti OpenCTF   aiuta a costruire test automatici per tutti   Componenti VCL (visivi e non visivi)   in un'applicazione Delphi. Si basa   sul framework DUnit.

Alcuni esempi di utilizzo:

• rileva valori di proprietà mancanti o errati, ad es. Pulsanti senza Azioni assegnate, Origini dati senza DataSet associato
• rileva gestori di eventi non assegnati - ad es. evento OnExecute mancante
• verifica che tutti i DataSet possano essere aperti
• controlla l'ordine delle schede
• trova componenti invisibili (ad esempio TabSheets invisibili che è meglio nascondere in fase di esecuzione)

OpenCTF http://www.mikejustin.com/images/OpenCTF.gif

Answer 5

Un altro approccio a questo problema è implementare un hook pre-commit nel tuo SCM. Uso TortoiseSVN e ho fatto cose simili per impedire che le cose entrino di soppiatto. Ad esempio, abbiamo un "skins" libreria che tenta di aggiungere circa una dozzina di skin skin a qualsiasi modulo che apri nell'IDE. (Abbiamo una patch di registro che "risolve" questo comportamento, ma viene "non fatto" ogni tanto, se uno sviluppatore reinstalla i componenti). Quindi ho un "elenco di stringhe vietato" in un file .ini che si trova in un hook pre-commit SVN.

Nel nostro ambiente, tutto il codice di produzione è costruito su una "macchina di compilazione" dedicata, quindi se il codice non viene archiviato, non viene inserito nella build. Problema risolto.