Support pebble push testing in harness
See original GitHub issueUse case
A recent commit pushed much needed support for ops.harness
based unit testing of sidecar charms. However any method that involves a pebble.push()
will raise an NotImplementedError
. It will be useful to have support for harness
based testing of such methods too, even though it is currently possible to write unit tests by mocking the push()
method. Mocking may allow checking what is being pushed however testing code downstream of the push call may become more involved, if it depends on the pushed content.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:7 (7 by maintainers)
Top Results From Across the Web
How to test a charm - Juju
The Charmed Operator Framework provides a testing harness, so you can check your charm ... testing pebble events and sidecar container interactions, etc.)....
Read more >Integrate Tests into Harness Workflows - Harness.io Docs
You can integrate testing into Harness Workflows, such as unit, functional, and smoke and sanity tests. In this topic we will walk you ......
Read more >Operator Framework 1.4.0 - Juju Discourse - Charmhub
Memory efficient push of file(s) to pebble; Testing harness more closely matches live environment behavior; Added flag to test with “real ...
Read more >Embedded C/C++ Unit Testing Basics - Interrupt - Memfault
An overview of unit testing embedded software and firmware. ... To build and run this unit test, we give the unit test harness...
Read more >Maxi-Cosi Pebble 360 and Pearl 360 Review - YouTube
Something that is so popular at the moment in the car seat world is rotating car seats, and the new 360 Family is...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
In which case you really need to do it only in memory, as there may not be a ‘mongod’ user on your host system, but again it would likely exist inside the container image.
I certainly wouldn’t want people to have to patch the functionality to do basic testing. The question is more what leads to good, maintainable tests such that we can guide people towards high quality charms.
On Tue, May 4, 2021 at 9:25 AM Balbir Thomas @.***> wrote:
If you are asking why test suite needs to implement file storage on disk, it may be that it is probably not necessary and can as well be in memory as long as it can imitate behaviour of Pebble API (
push()
andpull()
). Although I wonder if there will be a need to unit test file permission and owner ship settings and if so, how this can be done with in memory representation of files. For example MongoDB is very stringent about the permission and ownership of the key file, when authentication is enabled. It insists that this key file is owned by user/group “mongodb” and that the permissions are read/write by owner only. If this condition is violated MongoDB fails to start. Setting owner, group and permissions is part of the Pebblepush()
API. The underlying question is if harness should allow unit testing all the functionality exposed by the Operator Framework API, without the need to patch the Operator Framework API itself. I can see there being divergent views on this. My own inclination is that making harness feature complete in this manner will be a more pleasant developer experience. Thoughts ?