UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[AlCalzone]

@Grizzelbee sagte in npm test failed:

JS-Controller is already running! Stop it for the first test run and try again!

Was ist daran denn nicht verständlich?

process.exit was called with the unexpected exit code 11!: expected [] to include 11

Während deinem Start wird die Konfiguration geprüft und wegen nicht vorhandener Konfiguration der Adapter mit Code 11 beendet (terminate).
Hierfür musst du die Unit-Test-Datei anpassen (test/unit.js)
==> https://github.com/ioBroker/testing#adapter-startup-unit-test

Entweder du ergänzt die nötigen Objekte, damit die Prüfung erfolgreich ist (overwriteAdapterConfig, oder du fügst Exit code 11 den erlaubten Exit codes (allowedExitCodes) hinzu.

[OliverIO]

hm, da ich die tests bei mir alle einzeln anstosse:

npm run test:package
npm run test:unit
npm run test:integration

ist das der fehler, der bei mir beim 3.Test (integration) kommt, wenn ich vergesse
vorher den iobroker zu stoppen. die anderen beiden können mit laufendem iobroker durchgeführt werden.
Beim integration-test wird ein zusätzlicher iobroker gestartet und das funktioniert natürlich nicht, weil da die selben ports schon alle belegt sind.

also einfach vor dem test
iobroker stop eingeben

ein anpassen meiner testdateien war bei mir nie nötig. sind alle noch standard

[Grizzelbee]

Hallo !

vielen dank für eure Antworten.

@OliverIO: das bloße stoppen von ioBroker reicht in meinem Fall offenbar nicht aus. npm test failed immer noch auf die selbe Art.

@AlCalzone: Eine echte Config kann ich leider nicht hinterlegen, weil da creadentials drin sind. Aber ich gucke mir das Thema Unit-Tets jetzt auf jeden Fall mal genauer an - wollte ich eh.

viele Grüße
Grizzelbee

[AlCalzone]

@OliverIO sagte in npm test failed:

ist das der fehler, der bei mir beim 3.Test (integration) kommt, wenn ich vergesse
vorher den iobroker zu stoppen

Je Adapter sollte das nur einmal nötig sein, da für die Tests ein temporärer JS-Controller in einem temporären Verzeichnis installiert wird. Fürs einmalige Einrichten müssen die Standard-Ports (9000, 9001) frei sein. Danach laufen die Tests mit dem umkonfigurierten Controller auf einem anderen Port.

[Grizzelbee]

Guten Morgen!

Ich brauche bitte noch einmal Hilfe mit diesem Thema. :(
Ich habe das Problem mit dem Exitcode 11 schon wieder:

  Test the adapter (in a mocked environment)
    √ The adapter starts in normal mode (112ms)
    1) The adapter starts in normal mode


  37 passing (28s)
  1 failing

  1) Test the adapter (in a mocked environment)
       The adapter starts in normal mode:
     Uncaught Error: Adapter.terminate was called (exit code 11): Invalid Configuration.
      at AdapterConstructor.terminate (node_modules\@iobroker\testing\build\tests\unit\mocks\mockAdapter.js:359:25)
      at Object.invoke (node_modules\sinon\lib\sinon\behavior.js:163:32)
      at AdapterConstructor.functionStub (node_modules\sinon\lib\sinon\stub.js:39:43)
      at Function.invoke (node_modules\sinon\lib\sinon\proxy-invoke.js:47:47)
      at AdapterConstructor.functionStub [as terminate] (node_modules\sinon\lib\sinon\proxy.js:214:26)
      at main (main.js:722:17)
      at adapter.getForeignObject (main.js:102:17)
      at AdapterConstructor.getForeignObject (node_modules\@iobroker\testing\build\tests\unit\mocks\mockAdapter.js:170:17)
      at Object.invoke (node_modules\sinon\lib\sinon\behavior.js:163:32)
      at AdapterConstructor.functionStub (node_modules\sinon\lib\sinon\stub.js:39:43)
      at Function.invoke (node_modules\sinon\lib\sinon\proxy-invoke.js:47:47)
      at AdapterConstructor.functionStub [as getForeignObject] (node_modules\sinon\lib\sinon\proxy.js:214:26)
      at AdapterConstructor.ready (main.js:91:21)
      at Object.<anonymous> (node_modules\@iobroker\testing\build\tests\unit\harness\startMockAdapter.js:97:45)
      at Generator.next (<anonymous>)
      at C:\Users\hanjo\WebstormProjects\ioBroker.mielecloudservice\node_modules\@iobroker\testing\build\tests\unit\harness\startMockAdapter.js:9:71
      at new Promise (<anonymous>)
      at __awaiter (node_modules\@iobroker\testing\build\tests\unit\harness\startMockAdapter.js:5:12)
      at Object.startMockAdapter (node_modules\@iobroker\testing\build\tests\unit\harness\startMockAdapter.js:37:12)
      at Context.<anonymous> (node_modules\@iobroker\testing\build\tests\unit\index.js:66:83)
      at Generator.next (<anonymous>)
      at C:\Users\hanjo\WebstormProjects\ioBroker.mielecloudservice\node_modules\@iobroker\testing\build\tests\unit\index.js:10:71
      at new Promise (<anonymous>)
      at __awaiter (node_modules\@iobroker\testing\build\tests\unit\index.js:6:12)
      at Context.<anonymous> (node_modules\@iobroker\testing\build\tests\unit\index.js:62:20)



npm ERR! Test failed.  See above for more details.

Ich verstehe aber nicht warum!

Sowohl in der Integration.js als auch in der unit.js habe den exitcode explizit erlaubt. Das hat ja auch eine ganze Zeit lang problemlos funktioniert.

Kann da bitte noch einmal jemand drüber gucken und mir einen Tipp geben? Ich stehe gerade echt auf dem Schlauch.

Vielen Dank im Voraus und viele Grüße
Grizzelbee

[AlCalzone]

@Grizzelbee Hast du mal einen Link zu nem Repo, wo ich das testen könnte?

[Grizzelbee]

@AlCalzone
Natürlich! Gerne. :)
https://github.com/Grizzelbee/ioBroker.mielecloudservice/tree/Development_V1.2.2

Am besten tatsächlich den 1.2.2 Branch. Dann könnte ich den Fix dort unterbringen und anschließend mergen. Am Ende ist mir aber jede Lösung recht.

[AlCalzone]

@Grizzelbee Ehrliche Antwort: Lass den Unit-Test weg, also nicht npm run test:unit als Teil des Testings ausführen.

Das Problem ist folgendes: deine on("ready")-Methode ruft eine Funktion mit callback auf, und darin wird der Prozess beendet (terminate aufgerufen). In Unit-Tests wird ein beendeter Prozess über Errors abgebildet, das geht im vorliegenden Fall einfach nicht sauber, weil der Error erst nach dem durchgelaufenen Test aufschlägt.

[Grizzelbee]

@AlCalzone
Herzlichen Dank für deine Mühe und vor allem die ausführliche Anrtwort - sie hat mich in die Lage versetzt die Lösung zu finden, die ich jetzt implementiert habe:
Da es mir nicht richtig behagt die Unittests einfach zu entsorgen (ich möchte die ja schon noch implementieren) und Du gesagt hast, das das eigentliche Problem die Callback in der main() ist (die ich allerdings nicht als solche erkenne) habe ich jetzt die
Prüfung der Config, die ja das terminate auslöst aus der main() herausgenommen und in die on(Ready) verlagert.
Das bestätigt deine Aussage und die Tests funktierien. :)

Danke noch einmal und viele Grüße
Grizzelbee

[AlCalzone]

@Grizzelbee wichtiger sind die Integration tests, die einen echten js-controller verwenden. Code verbiegen, um den speziellen Anforderungen der unit tests gerecht zu werden ist imo unnötig.

[Grizzelbee]

@AlCalzone
Da gebe ich dir grundsätzlich recht.
Im vorliegenden Fall finde ich den Umbau aber sogar besser, weil ich jetzt vor dem Aufruf von Main() prüfe ob überhaupt die Voraussetzungen dafür erfüllt sind. Meiner Meinung nach ist der Code dadurch besser geworden.

Viele Grüße
Grizzelbee