Well, it's about hidden details. Erlang is pretty straightforward language; C is a lot more tricky to make right. So there is a lot of non obvious bugs that I can't foresee when I write unit tests; PropEr's *random* tests are way better in this sense, because you just describe the domain of your task, not particular cases. You can also test your NIF incrementally, writing property after property (or command after command if there is some state involved).<div>Speaking about my experience — I'm using PropEr to test this library <a href="https://github.com/band115/ecirca">https://github.com/band115/ecirca</a> , that implements mutable circular array in Erlang (all calls to this array are constrained to it's creator, so I hope this mutability can't be a problem). There are no docs right now other than code; I will definitely fix it in a week or two when I'll have more time. I've tried to test it with EUnit when it was just plain array; but then I've added different types of array and realized that I should add like 5 times more code to cover all cases, and there was a thought about adding different types of values (int16/32/64), so I realized than EUnit is definitely not the best tool, just because the space of inputs is so multidimensional (and I really wanted to cover as much of it as I can with tests — Erlang's VM is very fragile to NIFs after all). So I started to dig into PropEr's docs, wrote first commands/checks for statem, compiled a debug version of BEAM, made a habit to attach GDB to the process running tests (this way in case of segfault, and I had a lot of them, I can quickly find where I broke the code) — and right now I can be sure to some degree (which is proportional to amount of tests that you've asked PropEr to do) that this NIFs won't explode in my face tomorrow.</div>