Filter subscribe on --product. - #149
Conversation
…s on mms commandline tool. Makefile with test_integration rule.
|
I forgot to fix api-key generation on integration_tests. Set as draft until thats fixed. |
…sts require env variable with api key.
No, I don't think so either, we just assumed that it had some hidden purpose that we can't see yet. This is easier to read 👍🏻 Good idea with the integration test. |
| go-plantuml generate -rd . -o go-mms.puml | ||
|
|
||
| test_integration: build_mmsd | ||
| $(eval MMSD_KEY=$(shell ./mmsd keys --gen|awk 'NR==1{print $$3}')) |
There was a problem hiding this comment.
This populates the default state.db with keys, maybe some tmp state.db would be better?
There was a problem hiding this comment.
Good point, that would be better. I guess then, you would check in that file, and start mmsd with ./mmsd -w ./test_dir, or something like that?
There was a problem hiding this comment.
Why is the DB in the repo now?
There was a problem hiding this comment.
Ah, I see. It's for tests, right? If so, that may clutter the initial config space of a new instance of mmsd. It would probably be better to put it in a folder for test files, or generate it for the test as I think @mpejcoch suggests?
There was a problem hiding this comment.
This was what I meant, yes. Generate it on start, but give it a -w <temp_test_dir> so that it doesn't interact with whatever might be present from before. It is perhaps less of a problem when the testing is going to be done in a fresh container, so far we need to count on this being built and deployed on the PPI nodes too.
I see an advantage of having the DB in the repo though, which is that it would catch possible regressions towards the DB structure, as the state.db is something that users will keep after upgrading to a new mmsd version.
There was a problem hiding this comment.
But a populated db will cause conflicts if it is run from a git clone, so it's a bit risky to version control it.
There was a problem hiding this comment.
Having a committed db isn't in itself a problem in my opinion, but it shouldn't be located at the default location in the repo, but rather in a resource folder for tests that mmsd is pointed to. Then there is no risk of conflicting with a live db.
There was a problem hiding this comment.
Aha! I misunderstood Martin to begin with. But it simplifies things, to have a static test db in repo, to avoid having to dynamically set api keys for the integrations tests etc.
So, maybe its ok to create have in ./test_data/state.db?
There was a problem hiding this comment.
Yes, that sounds like a good solution.
Yeah, we didn't understand why but also didn't try to change it :) |
4 participants
Refactor to allow for integration tests on mms commandline tool. Makefile with test_integration rule.
Commands now get used directly, that is, without calling a funcation that returns a function. Since there was no closures there, I don't think the added indirection was needed?
Filter by product on both productReceive and command callback function.