Thread overview
How come unittesting std.socket takes 46 seconds?
May 01, 2021
Vladimir Panteleev
May 01, 2021
Vladimir Panteleev
May 01, 2021
Vladimir Panteleev
May 01, 2021

The second longest unittest is like 1.5 seconds.

I assume it goes outbound and initiates actual connections. A unittest should not connect to other hosts than localhost.

May 01, 2021

On Saturday, 1 May 2021 at 15:01:31 UTC, Andrei Alexandrescu wrote:

>

The second longest unittest is like 1.5 seconds.

~/work/extern/D/phobos/std » dmd -main -unittest -version=StdUnittest socket.d && time ./socket
1 modules passed unittests
./socket 0.05s user 0.15s system 92% cpu 0.211 total

Between this and your AUTO_BOOTSTRAP woes, my most likely guess is that there is something wrong with your computer.

>

I assume it goes outbound and initiates actual connections. A unittest should not connect to other hosts than localhost.

Unfortunately that's not possible for things like testing DNS.

May 01, 2021

On Saturday, 1 May 2021 at 15:01:31 UTC, Andrei Alexandrescu wrote:

>

The second longest unittest is like 1.5 seconds.

I assume it goes outbound and initiates actual connections.

It would be good to test that theory. Could you please attach a debugger and check the stack trace?

May 01, 2021
On 5/1/21 11:30 AM, Vladimir Panteleev wrote:
> On Saturday, 1 May 2021 at 15:01:31 UTC, Andrei Alexandrescu wrote:
>> The second longest unittest is like 1.5 seconds.
> 
> ~/work/extern/D/phobos/std » dmd -main -unittest -version=StdUnittest socket.d && time ./socket
> 1 modules passed unittests
> ./socket  0.05s user 0.15s system 92% cpu 0.211 total
> 
> Between this and your AUTO_BOOTSTRAP woes, my most likely guess is that there is something wrong with your computer.
> 
>> I assume it goes outbound and initiates actual connections. A unittest should not connect to other hosts than localhost.
> 
> Unfortunately that's not possible for things like testing DNS.

A special dedicated test mode should be for that. Routine unittests should not connect to the network.

May 01, 2021

On Saturday, 1 May 2021 at 18:14:33 UTC, Andrei Alexandrescu wrote:

>

A special dedicated test mode should be for that.

There already is something like that: debug=std_socket (and used via softUnittest).

>

Routine unittests should not connect to the network.

Currently, an absence of Internet connection (without debug=std_socket) will not cause a failure.

However, the absence of an Internet connection should still not result in a very long test duration. I don't know for sure what causes this in your case. My first guess would be that the computer thinks it's connected to the Internet whereas it actually has no connectivity (e.g. it's connected to a network which advertises a gateway but all packets sent to it are actually dropped).

BTW, if this is still in WSL, I think that should be mentioned explicitly. I don't think we currently officially support that environment, and I'm not sure if we should expend much effort in doing so, considering that it's occasionally buggy and rapidly evolving. (I got bug reports that turned out to be due to filesystems in WSL behaving mysteriously and incorrectly, e.g. inability to rename a directory even with no processes accessing it.)