Integration tests don't work on Windows past first testcase

Hi,
when writing some AdditionalTests I found that the Redis service seems to break (Travis-CI job: https://travis-ci.org/github/Excodibur/ioBroker.schwoerer-ventcube/jobs/725840082):

The adapter started successfully.
    √ The adapter starts (5652ms)
 Objects 127.0.0.1:50062 Redis Socket error: Error: read ECONNRESET
 Objects 127.0.0.1:50063 Redis Socket error: Error: read ECONNRESET
 Objects 127.0.0.1:50064 Redis Socket error: Error: read ECONNRESET
 States 127.0.0.1:50065 Redis Socket error: Error: read ECONNRESET
 States 127.0.0.1:50066 Redis Socket error: Error: read ECONNRESET
 States 127.0.0.1:50067 Redis Socket error: Error: read ECONNRESET
    Adapter core functions
 Objects DB uses file write interval of 5000 ms

And for the next testcase this results in the following:

      1) should read correct values from Ventcube mock
 Objects 127.0.0.1:50069 Redis Socket error: Error: read ECONNRESET
 Objects 127.0.0.1:50070 Redis Socket error: Error: read ECONNRESET
 Objects 127.0.0.1:50071 Redis Socket error: Error: read ECONNRESET
 States 127.0.0.1:50072 Redis Socket error: Error: read ECONNRESET
 States 127.0.0.1:50073 Redis Socket error: Error: read ECONNRESET
 States 127.0.0.1:50074 Redis Socket error: Error: read ECONNRESET
 Objects DB uses file write interval of 5000 ms

Weirdly my mock-service I start as a background-service before the first testcase also works for that specific testcase, but is not reachable anymore for the second testcase. On Linux & OSX it works flawlessly, though.

Actually I see a similar behaviour also in other adapter integration tests, e.g. https://travis-ci.org/github/StrathCole/ioBroker.tahoma/jobs/668379396, so I guess it is not an isolated problem, but perhaps something to process-handling within test-harness or some Windows process handling problem.

Please give it a look.

@Apollon77 any idea what might cause this?

Actually, I might have an idea. @Excodibur can you try to stop the controller after each of your custom tests?
This is what the main integration test does internally:

testing/src/tests/integration/index.ts

Lines 117 to 122 in bfbb2bc

    
           // Stopping the processes may take a while 
        
           this.timeout(30000); 
        
           // Stop the controller again 
        
           await harness.stopController(); 
        
           harness.removeAllListeners();

Anyways, thanks for trying this out. I always wanted to, but never had the time to do any proper integration testing besides "does the adapters start?".

I'll give it a try.

Still I am wonding if it will help, since the logs seem to indicate that problem is caused at the end of the standard "adapter start" test, which I have no control over. When I get to the additional tests, it seems broken already.

Unfortunately, the result is the same: https://travis-ci.org/github/Excodibur/ioBroker.schwoerer-ventcube/jobs/725862384

I added the following lines beforehand:
https://github.com/Excodibur/ioBroker.schwoerer-ventcube/blob/3623554643c654000ee5dea53a3367bc61babd41/test/integration.js#L56-L57

Since my mockserver (port 10502) has similiar issues between tests (and that one is not controlled by test harness), I suspect it might even be something on Travis-side. According to them "Windows builds are in early-access stage", so maybe the issue originates from that.

Fyi, I can currently reproduce the same error behaviour on my local Windows 10 workstation, so I guess issues from Travis-CI are unlikely.

Ok that will help narrow it down. I should be able to reproduce it locally. Can you give me a branch or specific commit I can use to test myself?

Thanks! Commit Excodibur/ioBroker.schwoerer-ventcube@3623554 (currently latest) would be a good basis for tests.

ECONNRESET should mean that the db opened by the "controller part" was destroyed and so the DB was noh longer reachable, but adapter code was still connected. normally adapter should stop first and destroy the clientconnections before server is ended

Could you check if the problem persists with 2.4.2?

I updated iobroker/testing to 2.4.2 as suggested now.

It looks like it is working properly now:

Before
Test logs on Windows (with error)

 Objects 127.0.0.1:50076 Redis Socket error: Error: read ECONNRESET
 Objects 127.0.0.1:50077 Redis Socket error: Error: read ECONNRESET
 Objects 127.0.0.1:50078 Redis Socket error: Error: read ECONNRESET
 States 127.0.0.1:50079 Redis Socket error: Error: read ECONNRESET
 States 127.0.0.1:50080 Redis Socket error: Error: read ECONNRESET
 States 127.0.0.1:50081 Redis Socket error: Error: read ECONNRESET

After
Test logs on Windows (error gone, normal shutdown)

schwoerer-ventcube.0 (3000) Redis QUIT received, close connection
Server States 127.0.0.1:50255 close Redis connection
schwoerer-ventcube.0 (3000) Redis QUIT received, close connection
Server States 127.0.0.1:50256 close Redis connection
schwoerer-ventcube.0 (3000) Redis QUIT received, close connection
Server States 127.0.0.1:50257 close Redis connection
schwoerer-ventcube.0 (3000) Redis QUIT received, close connection
Server Objects 127.0.0.1:50252 close Redis connection
schwoerer-ventcube.0 (3000) Redis QUIT received, close connection
Server Objects 127.0.0.1:50254 close Redis connection
schwoerer-ventcube.0 (3000) Redis QUIT received, close connection
Server Objects 127.0.0.1:50253 close Redis connection
Server Redis QUIT received, close connection
Server Objects 127.0.0.1:50247 close Redis connection
Server Redis QUIT received, close connection
Server Objects 127.0.0.1:50248 close Redis connection
Server Objects 127.0.0.1:50248 close Redis connection
Server Redis QUIT received, close connection
Server States 127.0.0.1:50249 close Redis connection
Server Redis QUIT received, close connection
Server States 127.0.0.1:50250 close Redis connection
Server States 127.0.0.1:50250 close Redis connection

Thank you for fixing it! The issue can be closed.

	// Stopping the processes may take a while
	this.timeout(30000);
	// Stop the controller again
	await harness.stopController();

	harness.removeAllListeners();