Unit tests migration to pytest

[Batalex]

As a continuation of #774, here is a PR migrating the remaining unitests to pytest:

• The behavior of each test should not have been changed, I just used pytest shortcuts for some of them.
• I kept classes where I thought it was a nice scope delimiter

I do need some inputs however on:

• tests.unit.development.test_base_component.TestGenerateClass#test_call_signature. It has the following comment above: "# This one is kind of pointless now". Should I transform it to pytest anyway?
• tests.unit.development.test_base_component.TestComponent#test_to_plotly_json_with_nested_children does not seem to test anything, the assertion is enclosed in triple quotes. What should I do with it?

Contributor Checklist

• I have broken down my PR scope into the following TODO tasks
  • Migrate units tests to pytest
• I have run the tests locally and they passed. (refer to testing section in contributing)

(edit by ACJ - removed unneeded steps. Thanks!)

[alexcjohnson]

• tests.unit.development.test_base_component.TestGenerateClass#test_call_signature. It has the following comment above: "# This one is kind of pointless now". Should I transform it to pytest anyway?

I agree, that test is a bit silly. 🔪

• tests.unit.development.test_base_component.TestComponent#test_to_plotly_json_with_nested_children does not seem to test anything, the assertion is enclosed in triple quotes. What should I do with it?

LOL it's been that way for 2 years

🔪

[byronz]

Looks good! thanks @Batalex

[byronz]

@Batalex this is a direct conversion from the original test right? I don't like the check line by line, it looks long and error-prone with the long list of strings.

Can we just check the hash of the content ? like hashlib.md5(string).hexdigest(), the hardcode part will be a simple digest string.

[Batalex]

@byronz If you are okay with that, I replaced those functions with difflib. I think the hash approch is much harder to debug and equivalently error-prone.
Hardcoding the digest string would indeed be more concise, but we would not have any way of knowing why two hashes are different and this would require an extra step every time the docstring template is changed.
Even if we keep the hard coded docstring and compute the hash at runtime, the difficulty to figure out why the hashes are different remains

I also changed some other utils functions, all assert are back in the tests

[byronz]

@Batalex I'm sorry for the late reply, I was on vacation last week. what's the difference of using the difflib vs pytest's own diff mechanism? did you find it more readable?

[Batalex]

No worries !
The main advantage of using difflib instead of what we had before is that we can now detect multiple errors in one test run. The previous version would fail a test on the first different line regardless of the total number of lines changed whereas here we get a git-like diff with all changes

[byronz]

💃 @Batalex thanks for the contribution.