We have unit tests and there's a bunch of code we're not testing. But it would be a good exercise in dev tooling development to write a real-world application which exercises our m3u8 package more thoroughly.
From there that focusses efforts on where in the package we should write tests.
For example, a tool which reads a master HLS playlist, and writes the contents of each media playlist to the filesystem.
That can involve decoding then re-encoding the playlist. If we hit things like tags or attributes we don't recognise or can't handle well, we can terminate the program. This also lets us spot bad error messages from our package.
hls.js maintains a list of active HLS streams available over the Internet at https://raw.githubusercontent.com/video-dev/hls.js/v1.5.11/tests/test-streams.js
We have unit tests and there's a bunch of code we're not testing. But it would be a good exercise in dev tooling development to write a real-world application which exercises our m3u8 package more thoroughly. From there that focusses efforts on where in the package we should write tests.
For example, a tool which reads a master HLS playlist, and writes the contents of each media playlist to the filesystem. That can involve decoding then re-encoding the playlist. If we hit things like tags or attributes we don't recognise or can't handle well, we can terminate the program. This also lets us spot bad error messages from our package.