Rémi Bernon (@rbernon) commented about dlls/dmime/tests/dmime.c:
+{
- IDirectMusicSegment8 *segment;
- IDirectMusicLoader8 *loader;
- WCHAR test_mid[MAX_PATH];
- HRESULT hr;
- load_resource(L"test.mid", test_mid);
- hr = CoCreateInstance(&CLSID_DirectMusicLoader, NULL, CLSCTX_INPROC_SERVER,
&IID_IDirectMusicLoader8, (void **)&loader);- ok(hr == S_OK, "got %#lx\n", hr);
- hr = IDirectMusicLoader8_LoadObjectFromFile(loader, &CLSID_DirectMusicSegment,
&IID_IDirectMusicSegment, test_mid, (void **)&segment);- ok(hr == S_OK, "got %#lx\n", hr);
- IDirectMusicLoader8_Release(loader);
- IDirectMusicSegment8_Release(segment);
So yeah, IMO this test should come first, as well as the next commit which checks that a band track is created.
What I would perhaps also do, to make it is easy to follow and verify the progression of the implementation, is to add end-to-end tests with the mock performance tool (or synth that you can find in dmsynth tests, the midi messages aren't passed to the tool as I suspect they might), and check that playing that track produces the expected MIDI message sequence.
Then, as the parsing implementation progresses you can remove the todo_wine on the messages that are received.
In order to make it simpler you can do that in lock step with the implementation: use an empty MIDI file at first in the test, implement basic parsing, add a few messages in the MIDI file, implement the parsing for them, etc... until you have the parsing of all the MIDI feature you want.