Comments (10)
unittest
is based around a programmatic interface:
class ApertureTest(unittest.TestCase):
# Tests go here
Whereas pytest
just uses python assert
and has a command line interface.
from dlux.
I've made a new branch for this. I figured that we would be using the pytest
infrastructure, but there is also the option to use unittest
. We also have the option to set up a GitHub action to Automatically run the tests when we merge down branches.
from dlux.
Fantastic, not sure what the main difference between pytest
and unittest
are, maybe @benjaminpope has some thoughts?
from dlux.
So I have 500+ lines of tests implemented but have reached some of the more complex functionality. I was wondering how we wanted to go about testing correctness if at all. For now I have just left this blank, but I was wondering if we should consider places where there are simple analytic solutions or confirm against poppy
models. @benjaminpope and I spoke briefly but I don't remember what we decided.
from dlux.
I would do pytest
, simply because it is what I always use and it works well - if you have already implemented stuff in unittest
so long as it works no harm done.
I would say we should test correctness only for 2 examples:
- perfect circular aperture, test that we get the airy disk right (analytically or vs
poppy
) - simple Fresnel case, even from a circular aperture if we like, check that we get the same pattern as
poppy
So long as we test a few examples that should be fine to make everything else just a simpler test for the moment.
from dlux.
We do not have full and complete tests, but we do have the testing infrastructure built out, so I am closing this issue.
from dlux.
Hi all,
I thought it was worth re-opening this issue since the code has undergone large changes since the tests were written. They were never that good to begin with but they are pretty poor quality now. I think we need to rethink our testing strategy and try and test some more of the code since a large amount of it has been tested only by eye on specific examples. Due to the complexity I think that this is in general the way that it will go and we should prune back the testing code to deal with the helper.py
and coordinate.py
code which is used everywhere. I don't know though, let me know what you think.
Regards
Jordan
from dlux.
Yeah I agree - Due to the large number of rapid changes in the pre 1.0 phase, I figured tests were more of a hindrance than a help. As we edge closer to full release I think we should definitely start thinking about this some more.
The way I see it, anything that is in the docs should be tested, plus a few end-to-end tests. I don't think we need to build anything yet, but once we have the Source & Scene structure finalised then we should build the tests.
Open to other thoughts though.
from dlux.
Yep. Everything in the docs, end to end tests.
There is a way to do this automatically: if we make the docs notebooks into parametrized notebooks, eg here. We can then execute the notebooks using jupyter nbconvert
to run them as scripts in GitHub Actions (eg). We then simply do a couple of iterations in the optimization or MCMC loops, instead of tens or hundreds, and check that the results are finite.
I think also tbh that every Layer should be tested just that it instantiates and updates, but this is a lower priority.
from dlux.
Infrastructure built with 0.9.
from dlux.
Related Issues (20)
- pyproject.toml fixes HOT 1
- oversample in MFT? HOT 1
- change banner
- Add `CoronagraphicLayer` and `InterpolatedLayer`
- logo does not display on main README.md
- Add intrapixel sensitivity map downsampling HOT 1
- Add Convolution detector layer
- Missing `new_pixel_scale` return value in `utils.propagation.FFT` docstring
- ConcretizationTypeError in nd_coords HOT 5
- Inconsistency between parameter raising from `LayeredOpticalSystem` and `LayeredDetector`
- PointSource enforces flux as float HOT 1
- Remove all calls to `.normalise` when calculating things.
- HST-like Aperture Incorrect Size in Docs
- Add FoV method to child-classes of `ParametricOpticalSystem`
- `dlu.nandiv` fails on float inputs
- Github Pages inconsistent with latest docs HOT 1
- Cannot compute gradients for scalar parameters HOT 9
- Docs use old ChainConsumer API HOT 1
- Add diameter input to `zernike_fast` and `polike_fast`
- Add fill argument to `dlu.resize` and `dlu.pad_to`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dlux.