-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improving the test harness #332
Comments
@amotl This is a great start! One thing though. I think it would be helpful to distinguish between different types of tests.
All of these are valuable. From a quick read, it seems the tests you've added are more of the "system" variety. I'll try in the next day or so to write some "unit" tests with pytest, to compare. |
Let's please not scare away new module contributers (and old ones like myself) by making the test framework too complicated or complex to add to. One of our strengths in the past has been that we've had lots of service contributions, and I'd like that to remain thusly. Whatever test framework(s) we add should be as simple as possible to add to, please. |
@jpmens: I hear you and second your wish not to overengineer the software tests in order not to lose anyone on that. It's quite the opposite i am aiming at: To get everyone started to embrace the new tooling the mqttwarn code base will offer. My short-term goal is to gain a reasonable code coverage of Whether we will make up a contribution policy like "code + docs + tests" or relaxed variants thereof: Time will tell, we should decide later. Personally, i don't have strong opinions in this area, service plugins probably will continue to stay completely untested for a while, so there will be no barrier enforced to them in any way. The main intention is to test the core of mqttwarn thoroughly as safety tooling primarily used by us and all the core developers who dare to go into the details there in order to tame its intertwingulation. "How testing works" will be thoroughly documented as well, we can use the introduction above as a blueprint for that. I would like to hear some comments on the tests implemented by now. Modulo inline documentation, which i will definitively add, i find them reasonably easy to follow: What do you think? |
The test harness just succeeded on CircleCI for the first time [1]. Based on Thanks a bunch @hpk42, @nicoddemus, @RonnyPfannschmidt, @blueyed, @benjaminp, @asottile, @gaborbernat, @obestwalter, @themattrix and everyone who contributed. [1] https://app.circleci.com/jobs/github/jpmens/mqttwarn/4 |
Dear mqttwarn community,
this will be all about my proposal for finally giving mqttwarn a test harness in order to support the nice people caring about it, to make it more robust and to encourage future development, cleanups and refactoring of its internals.
Introduction
Along the lines of #127, @jpmens already asked for:
He got full acknowledgement:
As "later this year" might be just now and as i also was feeling your recent pain with #327 (thanks again, @robdejonge, @rgitzel and @jpmens), i again recognized the mental toll everyone pays each time when diving into the internals of mqttwarn in order to tweak something. Note to self: I can barely remember i came here for improving that - we finally should get the "develop" branch ready ;].
Tests FTW
So i just gave this a shot in the tests-ftw branch. It is the foundation for a full-fledged test harness based on the lovely and powerful pytest. The test harness is now able to boot mqttwarn in-process and run the message reception and transformation process through its core machinery - everything without any MQTT connection at all - making these kinds of tests real unit tests.
Test internals
You will find some basic unit tests in
test_util.py
and some more advanced ones intest_core.py
. The latter ones work by simulating a message delivery to thetest/log-1
topic registered byselftest.ini
while capturing the log output of the whole process. After that, the outcome is validated by checking for appropriate content in the log output to proof everything worked fine. This is the unit test variant of full end-to-end testing.Please note that mqttwarn is a multithreaded program, so the test suite has to account for asynchronous behavior of the "unit under test". Currently, it just issues a
time.sleep(0.05)
after the simulated message delivery in order to let the worker thread fulfill its job processing the message. It's a very low value which we might have to increase in the future depending on different systems, environments and quantities. By now, i chose this low value on purpose in order to make things snappy, which is very important to me (14 tests passed in 0.16 seconds
).Usage
Running the test suite should be as easy as issuing
Outlook
In order to improve the end-to-end testing even further, we will add full integration tests based on the even more lovely lovely.testlayers along the lines. This will spin up Mosquitto and mqttwarn as daemons and run the message delivery through regular MQTT without any mocking.
Have fun!
Cheers,
Andreas.
-- https://hooktube.com/watch?v=0TYnoYl1JfY
The text was updated successfully, but these errors were encountered: