in mock_ftplib.py, some file are set to Jan 19 2020, expecting in test to be in future
but this is not the case anymore... date should be placed at later date
Thanks for the heads up. The test code isn't written as carefully as the library code.
mock_ftplib.pyhas been removed in the repository because I'm using another mocking approach now (see ticket #98 and test/scripted_session.py). Nevertheless, there could be similar problems in the new code. I guess I'll check the tests when I'm working on #134, which I need to finish before the release of ftputil 4.0.0. I use the word "need" because dealing with #134 means a backward-incompatible change and I don't want to release a version 5.0.0 shortly after 4.0.0. ;-)
Again, thank you. :-)
I was just wondering why you would still use
mock_ftplib.pyand noticed that in the Mercurial repo browser the
masterbookmark is at January 2019 whereas the last commits on
masterare actually from the start of this year.
I pushed deliberately with
-B masternow and the repo view seems to be updated. I had assumed that the bookmark in the repo on the website would be updated if I had pushed the bookmark in the past.
I worked on ticket #134 during the last days and in the course of that hopefully made the tests more robust regarding year changes.
There's still one thing that depends on my environment, and at the moment I don't know how to fix this. In the integration tests
test_real_ftp.pyis a test method
test_time_shiftthat indirectly uses the function
def expected_time_shift(): """ Return the expected time shift in seconds. Unfortunately, the calculation may depend on the timezone of the server, i. e. the timezone used in directory listings coming from the server. So, depending on your test environment, you may need to change this function for your environment. _If_ you need an adapted `expected_time_shift`, please contact me (my e-mail address is in the ftputil documentation). In my particular case, I use Pure-FTPd as FTP server for the integration tests. At some point, it returned listings in the local timezone of the server, later it used UTC time, and now it uses the local timezone again. I wasn't able to find out why or how I can control this. """ raw_time_shift = (datetime.datetime.now() - datetime.datetime.utcnow()).seconds # To be safe, round the above value to units of 900 s (1/4 hours). return round(raw_time_shift / 900.0) * 900
This function has hardcoded knowledge about the settings of my local FTP server I use for testing. As far as I can tell, making this environment-independent would require an implementation similar to
synchronize_timeswhich wouldn't use
ftputilto get the timestamp of the temporary file, but instead a command line client and parse the output of the client to determine the date. However, this would contain similar code to
synchronize_timesand hence wouldn't be that useful because this code may contain the same or similar bugs as
synchronize_times(if there are any).
I guess long-term the best solution for the integration tests would be to create a container image that contains the FTP server with its environment (namely the timezone) and the test data.
Another approach could be to use a different FTP server whose configuration allows setting the time reported by the server to UTC. I didn't find such an option for Pure-FTPd.