Test driven development
All, or at least major, features of Backbone should have their own test. Whenever changes are made to the codebase, the tests would be run in order to see whether the new changes have caused any unexpected problems.
Once we have major features tested, we should also start writing a test for a new feature (should happen before the feature is implemented).
Major features to be tested:
- changing temporal resolution (e.g. 1 hour until hour 3, and then 4-6 and 7-9 -> roll with t_end = 9)
- stochastic model
- nodal energy balance
- also buying commodoties from a node
- unit conversion functions
- directOff
- directOnLP
- directOnMIP
- IncHR (with 2 and 3 levels)
- Lambda (with 2 and 3 levels)
- unit startup/online behaviour
- cold start only
- cold/warm/hot start
- minimum downtime/uptime
- multi-unit online constraint
- unit input/output constraints
- equality between two outputs
- valid operating area for two outputs
- ramp constraints
- ramp costs
- storage behaviour
- charging / discharging
- selfDischargeLoss
- bound start to end
- lower/upper boundaries
- boundaries with penalty
- reserves
- reserve procurement (just reserving)
- reserve release
- reserve to reserve
- N-1 reserves
- inertia
- max instantaneous share
- unit maximum upward/downward with reserve
- unit maximum upward/downward with online unit that is offline/online
- transfers
- basic transfer
- transfer losses
- policy constraints
- capacity margin
- emission caps
- max/min energy shares for groups of units
- investment behaviour