4 ms·

Even more than crappy laptop, please please test your application on bad/degraded networks. So many apps completely glitch and breakdown in bad network environm

Even more than crappy laptop, please please test your application on bad/degraded networks. So many apps completely glitch and breakdown in bad network environments.

deleted 5y ago
[deleted]
nine_k 5y ago
I've used toxiproxy [1] to imitate various network problems (slowness, lost packets, dropping connections, etc). It works pretty well, and is even amenable to running during functional / integration tests. [1]: https://github.com/shopify/toxiproxy https://github.com/shopify/toxiproxy
- faeyanpiraat 5y ago
  This looks amazing
paxys 5y ago
It's frustrating that this is so easy to do in one click using the browser's in-built developer tools, and yet no dev team spends their time on it (or even know that it exists).
- speedgoose 5y ago
  The built-in tools are a good start but they don't simulate most of network issues and don't do anything about existing websocket connections. On windows I used clumsy that was much more realistic. On some tablets, I used my microwave oven or my feets to walk away from the Wi-Fi.
LeonM 5y ago
This. 2 rules: - Always indicate that your application is performing a network action (like showing a spinner, disable forms/buttons while submitting, etc) - Always catch errors (including timeouts) and give some form of feedback to the user when something went wrong. Try letting your local development backend return a 500, timeout or a 4xx error every now and then, and check if your frontend handles this in a graceful manner. It should at least give some feedback to the user that the operation failed. You can emulate a slow internet connection in chrome devtools, though I find the experience not accurate. You can also just add a sleep() call somewhere in your local backend. Maybe inject a sleep() into your acceptance environment, and let the test team work through the scenarios with that sleep() call in place. I've seen so many frontends that don't catch errors, and just show the spinner indefinitely. Or worse, show nothing at all. This is extremely confusing to less technical people.
- usr1106 5y ago
  > Always catch errors (including timeouts) and give some form of feedback to the user when something went wrong. The worst offender I hit regularly is Google Meet. I use ADSL most of the day because it works just fine for most I do. Which is either local or ssh or looking up technical resources on the net. Even Google Meet works fine (I don't use a cam). Until I share my screen, which contains nothing but text in full screen. Then Google Meet will forever freeze the shared picture after a couple of minutes without anybody telling so. It's ridiculous that they cannot handle this reasonably, you don't need 30 fps to share a screen of slowly changing text. It's completely user hostile that there is no message for either the sharer or any participant that sharing has frozen and will never recover. This is paid usage of Google Meet.
  - kiwijamo 5y ago
    Having used a range of video conferencing systems, your description of Meet lines up with pretty much every Meet session I've been involved with. I'll meet the same group of people on Zoom another time and it usually works much better on Zoom. Meet = glitchy low-res videos, freezing screen sharing, etc even on high quality fibre connections Zoom = smooth high-res video and generally usable screen sharing (with minor glitches that usually sorts itself out in seconds) even on low quality connections The difference is like night and day, no joke...
    - usr1106 5y ago
      On 4G, which gives me 20 - 40 Mbit/sec uplink I have no major issues with Google Meet. Sharing terminals with red on black font does not work well. Whether Zoom works better I don't know from own experience. I hardly ever use it because my employer has a Google subscription. Well, sharing terminals over telcos is backwards anyway. We did that 20 years ago over 56 kbit/s modem lines using VNC. And the compression was lossless, the result pixel perfect.
cpeterso 5y ago
I can't find a source, but I heard that Google used to purposely slow down their corporate network on some days to force all teams to dogfood test their software on slow networks. Or maybe they just offered an alternate slow Wi-Fi network to make testing easier, not forcing everyone to use a slow network. But forcing managers to use a slow network would be an effective way to get them to prioritize performance. If using a slow network is a choice, they wouldn't.
- ehsankia 5y ago
  Idk about the main network, but they do have a separate "Google-2g" network you can connect to that has degraded performance for testing purposes. Maybe they force people to use it when testing apps?
  - cpeterso 5y ago
    The Google-2g network is what I must have heard about. Thanks!

Even more than crappy laptop, please please test your application on bad/degraded networks. So many apps completely glitch and breakdown in bad network environments.

deleted 5y ago

[deleted]

nine_k 5y ago

I've used toxiproxy [1] to imitate various network problems (slowness, lost packets, dropping connections, etc). It works pretty well, and is even amenable to running during functional / integration tests. [1]: https://github.com/shopify/toxiproxy https://github.com/shopify/toxiproxy

faeyanpiraat 5y ago
This looks amazing

paxys 5y ago

It's frustrating that this is so easy to do in one click using the browser's in-built developer tools, and yet no dev team spends their time on it (or even know that it exists).

speedgoose 5y ago
The built-in tools are a good start but they don't simulate most of network issues and don't do anything about existing websocket connections. On windows I used clumsy that was much more realistic. On some tablets, I used my microwave oven or my feets to walk away from the Wi-Fi.

LeonM 5y ago

This. 2 rules: - Always indicate that your application is performing a network action (like showing a spinner, disable forms/buttons while submitting, etc) - Always catch errors (including timeouts) and give some form of feedback to the user when something went wrong. Try letting your local development backend return a 500, timeout or a 4xx error every now and then, and check if your frontend handles this in a graceful manner. It should at least give some feedback to the user that the operation failed. You can emulate a slow internet connection in chrome devtools, though I find the experience not accurate. You can also just add a sleep() call somewhere in your local backend. Maybe inject a sleep() into your acceptance environment, and let the test team work through the scenarios with that sleep() call in place. I've seen so many frontends that don't catch errors, and just show the spinner indefinitely. Or worse, show nothing at all. This is extremely confusing to less technical people.

usr1106 5y ago
> Always catch errors (including timeouts) and give some form of feedback to the user when something went wrong. The worst offender I hit regularly is Google Meet. I use ADSL most of the day because it works just fine for most I do. Which is either local or ssh or looking up technical resources on the net. Even Google Meet works fine (I don't use a cam). Until I share my screen, which contains nothing but text in full screen. Then Google Meet will forever freeze the shared picture after a couple of minutes without anybody telling so. It's ridiculous that they cannot handle this reasonably, you don't need 30 fps to share a screen of slowly changing text. It's completely user hostile that there is no message for either the sharer or any participant that sharing has frozen and will never recover. This is paid usage of Google Meet.
- kiwijamo 5y ago
  Having used a range of video conferencing systems, your description of Meet lines up with pretty much every Meet session I've been involved with. I'll meet the same group of people on Zoom another time and it usually works much better on Zoom. Meet = glitchy low-res videos, freezing screen sharing, etc even on high quality fibre connections Zoom = smooth high-res video and generally usable screen sharing (with minor glitches that usually sorts itself out in seconds) even on low quality connections The difference is like night and day, no joke...
  - usr1106 5y ago
    On 4G, which gives me 20 - 40 Mbit/sec uplink I have no major issues with Google Meet. Sharing terminals with red on black font does not work well. Whether Zoom works better I don't know from own experience. I hardly ever use it because my employer has a Google subscription. Well, sharing terminals over telcos is backwards anyway. We did that 20 years ago over 56 kbit/s modem lines using VNC. And the compression was lossless, the result pixel perfect.

cpeterso 5y ago

I can't find a source, but I heard that Google used to purposely slow down their corporate network on some days to force all teams to dogfood test their software on slow networks. Or maybe they just offered an alternate slow Wi-Fi network to make testing easier, not forcing everyone to use a slow network. But forcing managers to use a slow network would be an effective way to get them to prioritize performance. If using a slow network is a choice, they wouldn't.

ehsankia 5y ago
Idk about the main network, but they do have a separate "Google-2g" network you can connect to that has degraded performance for testing purposes. Maybe they force people to use it when testing apps?
- cpeterso 5y ago
  The Google-2g network is what I must have heard about. Thanks!