public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Stefan Hanreich <s.hanreich@proxmox.com>,
	Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] fix #4095: make http client read proxy config from envvars
Date: Fri, 16 Sep 2022 10:34:32 +0200	[thread overview]
Message-ID: <0db22740-013f-d1c6-2d82-47a2d853022f@proxmox.com> (raw)
In-Reply-To: <1d9bffa3-950b-360a-e472-8633fad2b49e@proxmox.com>

Am 16/09/2022 um 10:17 schrieb Stefan Hanreich:
> Yes, I was also not very happy with how I had to test it. If i really wanted to test it properly I'd add tests to the ProxyConfig as well as the HttpsConnector, but that seemed a bit out of scope for this patch series, which is why I resorted to this (seemingly) basic test.
> 
> It was more of a basic sanity check to see if I didn't break some stuff.

Sure, but test code should be near the thing actually tested. Note also that
if we would add https to ProxyConfig in the future it would fail a "distant"
crate in a bit confusing way (the "slightly confusing" part could probably be
avoided by checking either the actual error or a comment for why it's expected
to fail), all noticeable and thus fixable before rollout, so nothing _that bad_,
don't get me wrong, but it would Just Work™ otherwise.

I'm also a bit wondering how setting environment variables affects other tests in
general, iow. how isolated this all is. I'd not 100% sure if rust spawns a separate
process per test and also then it may be a bit cleaner to first get the current env
variable one is modifying and restoring that value at the end of the test. I don't
think that would be an issue here, as we shouldn't rely on any connections at all,
so more of a general wondering-thing.

> Do you think it would make sense to create a separate patch series that unit tests ProxyConfig with some (im)possible proxy settings?

The current ProxyConfig is 89 Lines with comments and generous extra lines
of rather straight forward code, so while a clear cut specific test definitively
wouldn't be hurting, investing to much time in any would probably amount to a
rather mediocre ROI. With that in mind: your choice, if you send a somewhat sensible
one I'll definitively apply it.




      reply	other threads:[~2022-09-16  8:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-15 14:08 Stefan Hanreich
2022-09-16  6:58 ` Thomas Lamprecht
2022-09-16  7:08   ` Stefan Hanreich
2022-09-16  8:09     ` Thomas Lamprecht
2022-09-16  8:17       ` Stefan Hanreich
2022-09-16  8:34         ` Thomas Lamprecht [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0db22740-013f-d1c6-2d82-47a2d853022f@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    --cc=s.hanreich@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal