IA-2986: Have "sub org unit types to display" by default

[butofleury]

Related JIRA tickets : IA-2986

Self proofreading checklist

• Did I use eslint and black formatters
• Is my code clear enough and well documented
• Are my typescript files well typed
• New translations have been added or updated if new strings have been introduced in the frontend
• My migrations file are included
• Are there enough tests
• Documentation has been included (for new feature)

Changes

Setting up default sub org unit type.

How to test

Launch setuper to generate data and check the org unit type page: http://localhost:8081/dashboard/orgunits/types/.

You should see sub org unit type.

Print screen / video

Once the test data created, check the org unit type page: http://localhost:8081/dashboard/orgunits/types/

Sub-Org-unit-type.mp4

[kemar]

Is this test supposed to cover setuper.pyramid.update_org_unit_sub_type?

I'm asking because the logic seems replicated.

[butofleury]

yes, It's supposed to cover setuper.pyramid.update_org_unit_sub_type

[kemar]

Ok.

In fact, the test shouldn't re-implement the logic. Otherwise, if you change the function, the test will continue to work.

So, it would be better if setuper.pyramid.update_org_unit_sub_type could return something that you can test to ensure that it's doing what you want.

[kemar]

I have a question in comments.

[kemar]

LGTM (the test could go one step further, it's up to you to decide)

[kemar]

Do we know the expected new sub types here?
If so we should test that too in addition to testing the returned HTTP code.

[butofleury]

I am wondering for testing the expected new sub type, if from the line 27 we filter on the expected new sub types with ;

expected_new_sub_types = []
for org_unit_type in response_data["orgUnitTypes"]:
    org_unit_type_level = org_unit_type["depth"]
    sub_unit_type_ids = [
        org_unit_type["id"]
        for org_unit_type in response_data["orgUnitTypes"]
        if org_unit_type["depth"] == (org_unit_type_level + 1)
    ]
    expected_new_sub_types.append(sub_unit_type_ids)

But, it looks a re-implement of the logic of update_org_unit_sub_type

Then, from line 29

updated_sub_types = []
for org_unit_type_with in updated_with_sub_types:
    self.assertJSONResponse(org_unit_type_with["updated_org_unit_typs"], 200)
    updated_sub_types.append(org_unit_type_with["sub_unit_type_ids"][0])

sub_types_ids = reduce(lambda a, b: a + b, expected_new_sub_types)
self.assertEqual(updated_sub_types, sub_types_ids)

[kemar]

TBH I don't know if it's doable?

My point is that In general, we know what we are expecting from a test:

expected_result = "foo"

result = test_my_function()

assert result == expected_result

Here, the only thing that you are testing is that the API call returns 200, but we don't know if the data was modified in the expected way.

We can discuss this tomorrow, it may be easier to talk about it.

[madewulf]

Are we really doing tests on the setuper? I'm thinking this might be overkill.