Initial test case validation using pyucis #23
Conversation
|
This works for the pyucis test. |
| @@ -103,7 +103,7 @@ SC_MODULE(stimulus) { | |||
| bin<int>("invalid", 0) | |||
| }; | |||
|
|
|||
| cross<int, int, int> reset_valid_cross = cross<int, int, int> (this, "reset valid", | |||
| cross<int, int, int> reset_valid_cross = cross<int, int, int> (this, "reset_valid", | |||
There was a problem hiding this comment.
The spaces in the name cause problems with my bash code parser. Its a preference to fix. FWIW, the output does not match the golden coverage report either. ie. foo[1] vs foo_1. I can handle either but spaces cause me to have to tweak the code.
If its a problem I can reverse this one. I was just thinking ahead. I don't know if the pyucis one has a problem with it to be honest. I do know the sample I am looking at has all _ separated names. FWIW the spec says this, but I am not entirely clear about the spec:
4.8.3 Variable names as naming components
Variables and parts of variables are identified by language-appropriate string names with no unnecessary white space.
| @@ -246,7 +246,7 @@ class covergroup : public cvg_base | |||
| << "\" line=\"" | |||
| << "1" | |||
| << "\" inlineCount=\"1\"/>\n"; | |||
| stream << "<ucis:cgSourceId file=\"" << file_name << "\" " | |||
| stream << "<ucis:cgSourceId file=\"1\" " | |||
There was a problem hiding this comment.
There are hardcoded 1's and "KEY" in the code. The sample xml I am looking at has 4625 key="0" in it. It also has 54 entires which look like this
<ucis:cgSourceId file="1" line="1" inlineCount="1"/>
None have a value other than 1.
| @@ -0,0 +1,22 @@ | |||
| # venv notes | |||
There was a problem hiding this comment.
These are personal notes and don't belong to this project.
There was a problem hiding this comment.
I figured it would help with someone who wanted to run the same setup, but sure I can back it out.
test/pyucis-fir/test_ucis_xml.py
Outdated
| @@ -0,0 +1,13 @@ | |||
|
|
|||
There was a problem hiding this comment.
Can this test (and directory) fit into established Makefile-based testing harness developed by the author?
There was a problem hiding this comment.
I can redo as a test in the makefile or even with bazel. I'm just trying to get something in simply as part of the small diff procedure and elaborate on it as time progresses. Your call as to which objective.
test/pyucis-fir/test_ucis_xml.py
Outdated
| @@ -0,0 +1,13 @@ | |||
|
|
|||
| from io import BytesIO | |||
There was a problem hiding this comment.
Generally files name test_XYZ are unit tests and are compatible with unittest python (i.e., executed with python -m unittest)
There was a problem hiding this comment.
Yes, it should have a "expect this vs actual result" and be a proper test.
test/pyucis-fir/test_ucis_xml.py
Outdated
| from io import BytesIO | ||
| import os | ||
| from ucis.xml import validate_ucis_xml | ||
|
|
There was a problem hiding this comment.
indeed. I'll do a apt install pylint. Its currently not installed.
|
This has pylint in requirements.txt, suggested mods and afterwards |
|
hmm I'm thinking about modifying the example/fir/Makefile and the test in an upper directory. My first inclination would be to have a parent Makefile and a second test/Makefile and a third test/pyucis-fir/Makefile. That might be overkill but perhaps I can use a top level dir spec. I'll also assume the user is using a similar venv setup. |
|
Added two Makefiles to get test scaffolding in place. |
|
hmm. pyucis repo has a makefile in its docs folder which uses venv. It will setup venv for you. That is a clever approach which should be done here. |
|
This is in conjunction with this pull request for pyucis later I will convert to google unit tests instead of unittest unittests. |
Starting point for pyucis validation.