Is any kind of mocking already present in Rockstors test code?
Otherwise I could (time-permitting) try making a prototype PR with unittest.mock in action.
I would start on this part of code first:
Here we can see productive code mixed with testing code, which should be separated.
In this case the code pertaining to testing would be moved to out to a unit test or a test base class or maybe even a test helper class.
The line with run_command() would probably need to be extracted into its own method, so we can mock it later.
Then, within a unit test we read from a smart dump, instead of actually running smart --info.
And then we do various asserts on that dump.
Above trimmed as too long for forum post (several hundred lines).
or:
grep -R "mock" /opt/rockstor/src/ | wc -l
815
The in-code ‘test’ mode we have in smart is unique in that respect. At the time we needed a quick and dirty but extremely robust way assess user submitted smart results. This was that way, along with the associated bash script referenced by me here:
To run all our current tests just do the following (long hand for clarity):
export DJANGO_SETTINGS_MODULE=settings
cd /opt/rockstor/src/rockstor/
poetry run django-admin test
which should give you approximately:
Creating test database for alias 'default'...
Creating test database for alias 'smart_manager'...
System check identified no issues (0 silenced).
............................................................................................................................................................................................................................................
----------------------------------------------------------------------
Ran 236 tests in 22.670s
OK
Destroying test database for alias 'default'...
Destroying test database for alias 'smart_manager'...
Or use a verbose test option like:
rleap15-4:/opt/rockstor/src/rockstor # poetry run django-admin test -v2
Creating test database for alias 'default' ('test_storageadmin')...
Operations to perform:
Synchronize unmigrated apps: djhuey, messages, pipeline, rest_framework, staticfiles
Apply all migrations: admin, auth, contenttypes, oauth2_provider, sessions, sites, smart_manager, storageadmin
Synchronizing apps without migrations:
...
Above trimmed as too long for forum post.
This is I’m afraid another side effect of our recent non trivial change in build system from buildout to poetry:
making our current developer docs outdated and in need of a refresh.
Hope that helps and again apologies for our behind the times docs in both user and developer areas here, but all in good time and any assistance, such as you have yourself already been involved in, is always welcome.
Thanks again for yet more usefull observations. It all helps with seeing where we have gaps across the project. More eyes and all.
Great, thanks for the clarification and an intro into the area of tests!
I will take a look after I try to fix my PC and then the nvme SMART issue.
The idea is to provide two separate PRs. First the fix with test, and afterwards the attempt of reworking the aforementioned area.
Then we can discuss it some more.