Obviously you can test functions' contracts, especially for values like allocating 0 bytes, 1 bytes, maximum number of bytes and half of the maxium number of bytes (I assume that the allocator takes bytes as its argument). You can also check module's invariatnts, especially in cases when combinations of the arguments mentioned before are used in tandem for consecutive alloations and then deallocated. Not much more you can do, until you have some special features in your library.
But you can test performance, and this is something worth looking at. Check, for example, memory fragmentation for large number of random allocations and deallocations, with various parameters and scenarios — this is a very grave issue for allocators. How well your library perform if multiple threads work concurrently? Does it handle decently nearly-full scenario (use some fake memory limit to prevent OOM killer from kicking in in Linux!). Are there any differences between platforms? How does swapping affect your implementation? There is quite a number of possibilities to analyze here, and I believe you can learn much about performance by trying to deeply understand results you get — especially by trying to explore the results and search if tweaking some testing parameter doesn't provide more interesting irregularities.
]]>Other than that I'm trying to professionally get into the game industry. The one area that's always tripped me up is writing custom allocators. I figure if I lean how to Unit test a simpler example of an allocation scheme that would be applicable to designing more complicated allocators.
]]>