testing viz helper funcs

[jGaboardi]

This PR:

• adds testing for 4 viz funcs in their own module - moving toward #60
  • viz_class_path()
  • viz_class_location()
  • viz_class_param_plot()
  • viz_class_video()
• adds contest.py
  • add a command line argument to pytest of the environment type and adjust a test accordingly
• closes #64

[jGaboardi]

The viz_class prefix screams that this should be a viz module :). But I don't care that much.

This is a good idea. I can update this PR without much effort. Give me a thumbs here and I will do.

@martinfleis @anastassiavybornova

[martinfleis]

I implicitly meant that by factoring that to a module, we can use a module name instead of the prefix. But if you prefer an explicit name, I'm fine with that either.

[jGaboardi]

I implicitly meant that by factoring that to a module, we can use a module name instead of the prefix. But if you prefer an explicit name, I'm fine with that either.

No, that makes sense. Since there will likely be other functionality in viz that is not dealing with cases/classes, let's do something like this:

 viz.py
   | class_path
   | class_location
   | class_param_plot
   | class_video

You OK with that?

[martinfleis]

I'm still not sure what is meant by "class" here.

[jGaboardi]

I'm still not sure what is meant by "class" here.

I think it was some terminology that @anastassiavybornova introduced in identifying specific classes of simplification (where class can be interchanged with case) -- see the last cell here. Ana, please correct me if I am wrong.

I am open to adjusting names, etc. Trivial to do at this stage.

[anastassiavybornova]

@jGaboardi @martinfleis ah yes, "class" there came from me thinking of "classification" (as in: roundabout, intersection, highway junction, etc.) but probably not the best choice of terms for contexts where it could be confused with class as in object class in python. i don't have any strong opinions on alternatives. i think this is something to also decide at the moment of writing: do we want to come up with a classification/typology of different use cases and if so what do we want to call it? classification, typology, usecases?

[jGaboardi]

i think this is something to also decide at the moment of writing: do we want to come up with a classification/typology of different use cases and if so what do we want to call it? classification, typology, usecases?

I think either classification or typology are technical enough and would work well in the paper

not the best choice of terms for contexts

However, context might work well within the code base (at least for now). How do we think about:

1

 viz.py
   | context_path
   | context_location
   | context_param_plot
   | context_video

OR

2

 viz_context.py
   | path
   | location
   | param_plot
   | video

With (1) we can have other visualization functionality, but naming is a touch verbose. With (2) functionality will be restricted at the expense of cleaner names.

[martinfleis]

I'd go with the first one. Or you can do nested modules viz.context.path.

[jGaboardi]

I'll see about the viz.context.path structure.

[jGaboardi]

@anastassiavybornova @martinfleis

Should we also rename the usecases/ directory to contexts/?

If so, I'll open another issue for that and see about adjusting the notebooks, etc. in a follow-up PR.