It's a bit more complicated to make my level editor test-friendly than it was with the sprite editor... so allow me to recap how I proceeded with SEDS:

hmm ... je pensais que ce serait plus simple que ça d'adapter le code de LEDS pour qu'il permette le même genre de tests que celui de SEDS. En fait non. Sans doute parce que j'ai déjà essayé d'avoir une couche "modèle" pour LEDS mais qu'elle ne correspond pas assez bien à ce dont j'ai besoin.

Guidelines

the model captures all the information about internal state of the edited object.the UI code makes no access to the components of the model (i.e. a palette, a spritesheet, ...) without going through one of the model's functioncode within the model is free from any UI interactioneach UI component (aka *Window) has its corresponding model capturing the information it needs. When a component is used by multiple UIs, we'll use a common ancestor (e.g. ModelWithSheet) to capture the shared component.editor-specific extensions to the library component (e.g. EditorSpriteSheet extends SpriteSheet) is declared at the *Model.h level. Outcome
Every operation performed on edited objects can be reproduced out of native UI environment for testingDependent objects are created together as a *Model, making it simple to ensure they're working correctly with each other.main code no longer needs to maintain and dispatch pointers to shared component all over the place, while components themselves still blissfully ignore wher...