20,741
edits
(http://flightgear.org/forums/viewtopic.php?f=30&t=19948) |
|||
Line 56: | Line 56: | ||
I had the idea, which you implemented above, of just overriding the get/setprop un the scripts. I guess taking that Sudafed might pay off in more ways than one. | I had the idea, which you implemented above, of just overriding the get/setprop un the scripts. I guess taking that Sudafed might pay off in more ways than one. | ||
Ultimately what I'd like to have is an implementation of something like the jUnit/xUnit/nUnit testing frameworks. Tonight's goal will be to hack out a rough implementation that allows for isolation of the property tree. | Ultimately what I'd like to have is an implementation of something like the jUnit/xUnit/nUnit testing frameworks. Tonight's goal will be to hack out a rough implementation that allows for isolation of the property tree. | ||
== Integration == | |||
Unit testing support in Nasal would certainly be beneficial - but it would need to be added to FG at a library-level, i.e. in $FG_ROOT/Nasal, so that people have to use it, and have an advantage when using it - sort of like the RoR example you mentioned previously. | |||
I could see that being useful for many things, even outside aircraft development - but thinking in th most generic terms, we need to find a compromise that will not just work for specialists who have a decade of unit testing experience, but also our average aircraft developers. | |||
Scripting-wise, I think we really only got a handful of people here who regularly write Nasal code and who would also see the merits and potentially adopt the system. | |||
People would only be likely to actually use that if they have a corresponding developers background, so it would need to be designed right into the framework and touch lots of places in $FG_ROOT and $FG_AIRCRAFT - I only see a handful of aircraft developers here who would go that route and actually have the mental capacity, and developer mentality to see the merits here. |