So when verbose is True, it does not get the result which has its testcase_name as None. @giulia am I missing something?

Hello Yash, Your tests look good. I think I misinterpreted the request in the issue #292.
It says: "Test that when verbose=true is supplied, then greenwave should return even results for testcases on the subject that don't have a testcase name in the policy."

I thought it meant if testcase == null. But I checked the current dump of the resultsdb database in Fedora and I didn't find testcases == null (or empty string) -- and it doesn't make much sense actually...
Maybe I didn't understand what @ralph meant.
Ralph, could you explain that sentence a bit more?
I guess in the policy there shouldn't be the testcase name... what kind of policy should we put there?

Since this is here for a while... I tried again to understand what that should mean :D
And I think it is: when you ask for a decision with flag verbose=true, greenwave should request to resultsdb all the results (with the new version only the latest results) for a specific type (example: koji_build) and a specific subject_identifier (also named item, an example can be an NVR: systemd-219-62.el7_6.5).
But in this filtering there's no testcase. That means that ResultsDB should return all the results for those parameters and for each testcase. --> Greenwave should return those results when verbose=true because Bodhi will then show them in the interface.

So I think the test should have some policy like that:

   --- !Policy
    id: "policy_id"
    product_versions:
      - fedora-29
    decision_context: some-decision-context
    subject_type: koji_build
    rules:
      - !PassingTestCaseRule {test_case_name: testcase1}

And then the test should create 2 results with these data (same result, 2 different testcase):
- item: some-nvr.f29 -- type: koji_build -- testcase: testcase1
- item: some-nvr.f29 -- type: koji_build -- testcase: testcase2

Try to ask Greenwave's decision with flag verbose=true.
Greenwave in the results should return both these results, even if the policy that we configured only have the first testcase (testcase1).

I think that's what was meant.
Yash, can you try write this kind of test and see if it passes?

Thanks for the explanation Giulia! Yes, I'll try and write it up. :)

@gnaponie I'm facing some problems testing this due to vagrant. I'll resolve the WIP status once I am able to successfully run the tests.

What's the error you get?
I've pulled your changes on my instance and it works. Only one test fails, but it's not one of yours, so I guess that's my problem :)

@gnaponie I think this is ready to go.

The vagrant issues were related to fedora_messaging which we talked about :)

blacklist is actually deprecated... (https://pagure.io/docs/greenwave/ --> writing policies section).
We should update that in the whole file. But.. for this PR let's just remove it from here, and maybe we can submit another PR removing that from this file.

same as above

It looks good to me +1
I would just remove "blacklist" from the policies and we can merge it in my opinion.

Thanks Giulia! I have removed the blacklist

Eheh don't kill me, but can you amend the last commit message to be max 50 characters and the rest in the description (as in the best practices https://gitlab.cee.redhat.com/devops/factory2-best-practices/blob/master/git.rst )? And maybe put a brief description there of what the test does?

Do the functional tests run successfully for you? I tried to pull this code and they don't run correctly for me. It gives me error starting waiverdb's server. But I guess it might be my issue...

+1 looks perfect now! Thanks Yash!