I want to write an application that can be used to burn CDs (music). I know I should test it with real CDs anyway, but I don't want to do this every time I make a small change. But I do want to know and test if the right data will be burnt, so you don't get corrupted CDs.

I am using a library which only exposes APIs to directly burn to a physical drive; it doesn't allow you to write to a disk image (which would be much easier to test).

How could I test this without wasting CDs and time for every change/few changes I make?

  • 5
    Would it be possible to switch to a library that does allow you to write a disc image? Nov 4, 2011 at 16:34

5 Answers 5


The simple answer is often the best: re-writable CD's?

Also for saving time, write relatively small files. Only do larger files every so often.

  • 1
    I agree this is a simple and good answer, but if WTP wants to take testing to another level, mocking the API (see other answers to this question) will unlock a whole dimension of testing possibilities (as in, automated).
    – louisgab
    Nov 4, 2011 at 18:35
  • @louisgab I totally agree with you, when I wrote the answer I was only really addressing the point about wasting CDs. I fully expected another answer to come up with something better (and they have). If anything, I would recommend the mocking approach, and suggest my answer only when WTP actually wants to physically test the burning process.
    – Kevin D
    Nov 5, 2011 at 9:55

If you are on linux, you should be able to set up a "cd device" that is just a named pipe. Your api writes to the "device" and you hook the other end up to a program that lets you see what it does/convert it to a disk image. Lots of options there. See this article for info on named pipes.

Kevin's answer is far easier IMO.

  • 2
    I am actually on Mac OS X which is also a UNIX system. I'll give this a try.
    – user4595
    Nov 4, 2011 at 15:41

Write as many tests as you can that use a mock of the API of the library. This allows you to test your code in units. This shows that your code works within itself assuming that the library performs the way it is supposed to.

At some point, you will need to do integration testing that actually does use the library. But the point is that you already have a level of confidence with your own code before you get to the this point. Integration tests often take more time and resources, as you've seen. So thorough unit testing allows you to not rely completely on integration testing.


What testing are you exactly talking about?

Reading "I don't want to do this every time I make a small change" in your question, I imagine that you are talking about unit testing.

But later, you add that you're using an API which is in charge of burning data to CDs. If this API is tested and documented correctly, you don't have to deal with actual process of burning the data to the CD, and you don't have to test it. In this case, you deal with integration testing, that you don't have to do "every time [you] make a small change".

  • But I do need to know if I am using the API correctly.
    – user4595
    Nov 4, 2011 at 15:40
  • @WTP: see my edit. Also, a correctly written API would not allow you to create corrupted CDs by using it incorrectly. If it does this sort of things, you should probably search for another API first. An API is here to provide an abstraction and especially to avoid to deal with the ways to avoid corruption when saving data to a CD. Nov 4, 2011 at 15:46
  • You do have a point there. The API is very well documented.
    – user4595
    Nov 4, 2011 at 15:49


Since you want to test your software (not the API, nor the recorder), as Chris pointed, a mock of the API would be necessary.
For the integration testing, a reliable "ISO" recorder should allow you to automate the testing of the CD contents by analyzing the .iso file.
Actually burning a CD or DVD would not render conclusive results, since you wouldn't be able to determine whether the error cause is a defective CD, a defective recorder or a software bug, unless you want to perform quality statistics by recording multiple copies of the same disc (wich you apparently don't).
Good luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy