Cppunit effort: Difference between revisions

Jump to navigation Jump to search
m
Line 114: Line 114:
   |date  =  Mar 18th, 2017  
   |date  =  Mar 18th, 2017  
   |added  =  Mar 18th, 2017  
   |added  =  Mar 18th, 2017  
  |script_version = 0.36
  }}</ref>
== New SubSystem Design ==
For the new testing framework Edward would like to discuss ideas for refining the design of the subsystems, the subsystem manager, and the subsystem factory.
These ideas were touched on in other threads on the devel list. Currently, the subsystem dependency order is hardcoded into the fgCreateSubsystems() function of fg_init.cxx.
But for the test suite we need far more flexibility.
What Edward would really like is two new access points. These would require converting the basic subsystem manager to be far more "intelligent", probably requiring the merging of the subsystem factory ideas into the manager itself, as well as adding a dynamic dependency resolution algorithm to the manager.
# The first access point would be to initialise a subsystem manager instance at the start of a test. Then asking the manager for subsystem X to be started along with all its dependencies (essential ones that is, and maybe with a flag for optional dependencies as well). For this, each subsystem could return a vector of dependency names. The manager would then instantiate each of the subsystems (if not already done) and then ask them for their dependencies. The dependency chain could then be built up and stored, and the dependency resolution code could order the subsystems. This order could then be used for ordering all of the subsystem API calls (init, shutdown, and reinit being of interest).
# The second access point would be to initialise a subsystem manager and then ask it for subsystems X, Y, and Z without dependencies.
On top of this, the subsystem manager add() function would be used to pre-insert instantiated subsystems or dummy subsystems set up as desired for the test. These ideas could easily be implemented side-by-side with the current code, gradually merging in the subsystem factory code. Would such ideas fit into to the current architecture at all? <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36279380/
  |title  =  <nowiki> [Flightgear-devel] Designs for the subsystem manager/factory. </nowiki>
  |author =  <nowiki> Edward d'Auvergne </nowiki>
  |date  =  Mar 29th, 2018
  |added  =  Mar 29th, 2018
  |script_version = 0.36
  }}</ref>
One thing to be aware of, we do rely on the subsystem-groups to control order of processing with the update() call - and this is important for reducing latency in some situations (eg, FDM is processed before Nasal). There's probably no problem here, but in the past when the (hard-coded) subsystem creation code got changed, we did get some odd bugs due to a subsystem running before another, when previously it had run after. Hopefully, all the cases of that were fixed at the time, but there’s probably a few more lurking. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36279719/
  |title  =  <nowiki> Re: [Flightgear-devel] Designs for the subsystem manager/factory. </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Mar 30th, 2018
  |added  =  Mar 30th, 2018
  |script_version = 0.36
  }}</ref>
Howeve, if a new type of "update dependency" was also added, then it wouldn't be a problem. The subsystem manager could then build the dependency tree by asking for all required, optional, and update dependencies.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36280483/
  |title  =  <nowiki> [Flightgear-devel] Designs for the subsystem manager/factory. </nowiki>
  |author =  <nowiki> Edward d'Auvergne </nowiki>
  |date  =  Mar 31st, 2018
  |added  =  Mar 31st, 2018
  |script_version = 0.36
  }}</ref>
For now, the idea is writing an initial example on a testing branch just as a first experiment. But we could do this on next. We should develop this in combination with basic tests to avoid problems in unrelated tests. For the subsystem supplied dependencies, the following SGSubsystem base class public virtual functions are under consideration:
* dependenciesRequired()
* dependenciesOptional()
* dependenciesUpdate()
* dependenciesNonSubsystem()
The last would be useful in the test suite with subsystem manager flags tracking the initialiation status of non-subsystem components, e.g. FGRenderer and SGSky. Parsing this for all subsystems might make an interesting subsystem conversion todo list ;) The functions could return empty std::vector<std::string> objects for leaf nodes and non-implemented subsystems. For the rest, we will need to experiment a little. A nice initial isolated subsystem set would be useful to find.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36280483/
  |title  =  <nowiki> [Flightgear-devel] Designs for the subsystem manager/factory. </nowiki>
  |author =  <nowiki> Edward d'Auvergne </nowiki>
  |date  =  Mar 31st, 2018
  |added  =  Mar 31st, 2018
   |script_version = 0.36  
   |script_version = 0.36  
   }}</ref>
   }}</ref>

Navigation menu