SQL Fehler, war zuvor nicht da, seid ??? vorhanden.

[Jens Hartmann]

Zitat von Sherlock:

OT: Alter, mal im Ernst. Sowas darf eigentlich nicht passieren.

Da hast du völlig recht. Problem, war das ich diese Hardwarekomponente nicht zur Verfügung hatte und somit nicht prüfen konnte. Dann kam heute morgen aber der Stress.

Aber, dafür gibt es ja die DP. Deshalb nochmal danke.

MFG

Jens

[hoika]

Hallo,

Zitat:

Problem, war das ich diese Hardwarekomponente nicht zur Verfügung hatte

Ausrede !!!!

aber im Ernst.
Was hat denn eine Hardware-Komponente mit einem SQL-Zugriff zu tun ?

Keine ausreichenden Unit-Tests ?


Heiko

[Jens Hartmann]

Zitat von hoika:

Ausrede !!!!

aber im Ernst.
Was hat denn eine Hardware-Komponente mit einem SQL-Zugriff zu tun ?

Da hast Du ja recht, die Hardwarekomponente hat damit nichts zu tun. Aber das Problem ist, das die Daten, die in diese Tabelle eingefügt werden, von dieser Hardware erzeugt werden und über die COM-Schnittstelle eingelesen werden.

Daher, konnt ich das ja ohne Hardware schlecht testen.

Um diesen Test durchzuführen, müsste ich also einen Datensatz habe, welchen ich dann über eine z.B. Testfunktion in die DB einlese. Da ich das aber bis jetzt ncoh nicht gemacht habe, kann ich momentan das eintragen in diese Tabelle nur mit Hardware testen.

Ich hoffe auf Verständis.


Gruß Jens

[himitsu]

Falls du noch länger mit dem Programm zu tun hast, dann erstell dir doch eine Weiche.

Also da wo auf den COM-Port zugegriffen wird, könntest du stattdessen auf eine Pipe oder eventuell auch eine Datei (wenn nur gelesen wird) umschalten und dir so, auch ohne Hardware, Testdaten ins Programm einscheußen.

Man könnte auch eine ganze Komponente gegen eine Dummy-Komponente austeuschen.
> z.B. die COM-Port-Komponente

[Jens Hartmann]

Danke,

da bin ich jetzt dran am überlegen. Ich denke das ich mit einer Textdatei zurecht kommen, die wie meine Datensatz aufgebaut ist. Allerdings überlege ich noch wie man das am Sinnvollsten realisieren kann. Mache ich mir da einen nicht sichbaren Button auf meine Anwendung, welcher dieses einlesen durchführt?

oder, vieleicht ein Label oder so...

Gruß Jens

[WoGe]

Zitat von himitsu:

Also da wo auf den COM-Port zugegriffen wird, könntest du stattdessen auf eine Pipe oder eventuell auch eine Datei (wenn nur gelesen wird) umschalten und dir so, auch ohne Hardware, Testdaten ins Programm einscheußen.

Ich benutzte an solcher Stelle "echte Hardware". Ich simuliere Sensoren mit einem ATMega32. Das liegt daran dass die echte Hardware manchmal ein äußerst merkwürdiges zeitliches Verhalten hat, das mit lesen von Daten aus einem File kaum zu simulieren ist.
Wie könnte man sowas rein Softwaremässig simulieren?

@Jens: Genau deswegen ist die "Knopf-Methode" eher schlecht - außer es geht wirklich nur um die Datenbank.

Gruss
wo

[hoika]

Hallo,

der Fach-Begriff dafür heisst Mock-Objekt.

Wie das das umsetzt, hängt von deinen Wünschen ab.

Z.B. könnte man eine Boolean-Variable nehmen (bMock).

Ein Bsp. für einen DB-Zugriff, bei dem die DB auch nicht vorhanden ist
(ähnlich wie diene Hardware).

Delphi-Quellcode:

type
  TClass = class
    bMock: Boolean;
  end;

function CreateClass(bMock: Boolean = False): TClass;
var
  MyClass: TClass;
begin
  MyClass:= TClass.Create;
  MyClass.bMock:= bMock;
  Result:= MyClass;
end;


procedure TClass.ReadFromDB;
begin
  if not bMock then
  begin
   // normaler Zugriff
  end
  else
  begin
  // lese aus Textdatei
  end;
end;

Ja, ich weiss, dass ist nicht genau ein Mock-Objekt (das wäre ein eigenes Objekt),
aber man ist ja faul.

Beim Erzeugen der Klasse kann eine Boolean-Variable übergehen werden,
dann reagiert sie anders bei den internen methoden.

Auch Compilerschalter sind denkar.
{$DEFINE MOCK} {$IFDEF MOCK}

Mache ich aber nicht gern, weil man immer alles neu compilieren muss
bei einer Änderung.


Heiko