Commit Graph

16 Commits

Author SHA1 Message Date
EstherLerouzic
cb85b8fe2b Add a test with long propagation
Existing tests only cover short distances, and effect on accumulated
noise, especially when crossing ROADMs with equalization, are not well
reported on elements power prints.
With this long path, I can catch more printing inconsistencies.

Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I2d0e8ccbbd387a2cd6c645c07f4b5f75e4617c30
2022-11-02 12:05:26 +01:00
Jan Kundrát
0dc7d853ef Merge changes I7f6cc553,I0a6a8442,I34fe2dcf
* changes:
  requests: avoid TypeError
  add an invocation test with power saturation
  Update a roadm test to include more cases for power handling
2021-09-15 13:09:32 +00:00
EstherLerouzic
280443f17f add an invocation test with power saturation
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I0a6a8442326fdfb9c9922abf05aeee52cfa42090
2021-09-15 14:59:59 +02:00
Jan Kundrát
825d37c05c tests: add OpenROADMv5 example propagation
These numbers "appear to look sane" as per [1]. Let's make sure that the
config files are CI-tested.

[1] https://review.gerrithub.io/c/Telecominfraproject/oopt-gnpy/+/522340/1#message-b40ac2c839f138237139407374452f254c3b0b0d

Change-Id: Iad346a14ed12b984f90a40629c0339fa0823290e
2021-09-15 12:33:18 +02:00
Jan Kundrát
3ac9f90914 OpenROADM: mark example config files as v4 explicitly
The recent commit has added support for OpenROADM v5, the latest
published optical spec sheet. Given that the upstream project has
released v10 YANG files (but still just v3, v4 and v5 XLS sheets with
optical performance numbers), I think it would be rather misleading to
have both versioned and non-versioned config files -- especially when
the unversioned one refers to the oldest release, not the newest one.

Change-Id: I04109341724b51d276660d400c923dc28561aef2
2021-09-15 12:31:05 +02:00
Jan Kundrát
55932ee3e9 tests: handle Unicode properly for "expected console output"
Let's use the text mode everywhere because Unicode codepoints is what
matters. The only catch on Windows turned out to be the default file IO
encoding; forcing UTF-8 there fixes all issues in the CI (and it makes
sense because that file was written out in a UTF-8 locale, and the
system which runs the test suite might be set to something else.

This was a rather interesting debugging experience; passing logs over
the web and handling "strange" characters as utf-8 did not help.

Change-Id: I1fdbe3a115458558b27a81f9eab8e58c9605bae7
Bug: https://github.com/Telecominfraproject/oopt-gnpy/issues/358
2021-06-17 18:14:36 +02:00
Jan Kundrát
797a0856ec tests: Use a portable /dev/null file name
Bug: https://github.com/Telecominfraproject/oopt-gnpy/issues/358
Change-Id: Icbca94682ce0ded860ba6397e4445651b6a61f32
2021-06-17 16:20:49 +02:00
Jan Kundrát
3f58cbd559 tests: enable pytest's builtin multiline diffing
...because it works on strings while doesn't work on byte arrays.

Change-Id: I2bb3b5a0a3d6ad965321c58fb90a02341db66d0f
2021-06-09 21:17:21 +02:00
Jan Kundrát
b6daa15356 tests: include the OpenROADM amplifiers
Change-Id: I26d6ad422917fa6fd5943ffaa5da933c2acec80e
2021-05-31 16:41:13 +02:00
Jan Kundrát
9fd55a5289 XLS -> JSON conversion: add a nice program for this
Esther mentioned that it is useful for her to be able to convert from
XLS files to JSON files. Let's add a full blown script for this.

I've also taken the liberty to refactor the code a bit so that there's
no default value, and to modernize everything with pathlib a little bit.

Change-Id: I80e50fc1280003910242ce1ff9fc9ae66e6d275b
2020-06-10 12:14:41 +02:00
Jan Kundrát
8eb5980ca9 distribute example data along GNPy
I would like to create a package for distribution to PIP, and this seems
like the path of least resistance.

This is, apparently, the way for shippign arbitrary data with Python
[1]. I've at least tried to make it user-firendly via adding a simple
utility which just prints out whatever that data path is.

[1] https://python-packaging.readthedocs.io/en/latest/non-code-files.html

Change-Id: I220ecad84b1d57d01e3f98f15befc700bd97c0b8
2020-06-08 18:30:36 +02:00
Jan Kundrát
7f816eb6e7 tests: show that the examples still work when directly invoked
Since Ic4a124a5cbe2bd24c56e4565d27d313fe4da703f, there was no automated
test which would check if the generated examples *really* work. When I
was playing with this, I managed to break it at least once (especially
when working on overriding sys.args, i.e.,
I53833a5513abae0abd57065a49c0f357890e0820).

This now requires an equivalent of `pip install` before the tests can be
run.

Change-Id: I595a3efe29b3ee13800c5cb71f28a5f370988617
2020-06-08 18:28:59 +02:00
Jan Kundrát
0d1225824e tests: call our example entry points via functions
I would like to avoid that extra fork to a child Python interpreter (it
looks like something that can be easily avoided). It's something that's
possible now that the code ships just some trivial wrappers (which are,
in turn, needed for setuptools' `console_scripts`).

This cannot use the `capsysbinary` fixture for wrapping of stdout/stderr
due to something in pytest which already got fixed, but has not been
released yet (May 2020). Let's use `capfdbinary` which works fine.

Change-Id: Ic4a124a5cbe2bd24c56e4565d27d313fe4da703f
See-also: https://github.com/pytest-dev/pytest/pull/6926
2020-06-03 19:29:17 +02:00
Jan Kundrát
3548ed74e2 coding style: autopep --in-place --recursive --jobs 4 --max-line-length 120 gnpy/ tests/
Change-Id: I2f0fca5aa1314f9bb546a3e6dc712a42580cd562
2020-05-19 12:40:00 +02:00
Jan Kundrát
3b45968799 tests: Check if example code provides exact same output
Change-Id: I5938f85337e4254092683dadc806a0a419cb2a04
2020-04-22 13:18:46 +02:00
Jan Kundrát
c7d69b9a99 tests: Run examples via pytest
This will make it simpler to update coverage info. The pytest-cov plugin
that we're already using apparently makes this behavior supported, nice.

Change-Id: Ieafc0da99a8c325f5f2286ed11e66069e244e43b
2020-04-22 13:18:46 +02:00