While I think the topic is fine, I believe this exercise is quite flawed. It comes down to the lack of considerations of the rounding/precision that should be used - or further specification on how to achieve a certain precision. I can also see the main headache in the comments below seem to be caused by rounding/truncation errors.

First of all, I'm surprised to see that I just got 11 passed tests with the following piece of code

public static string converter(double n, int decimals, double nbase)
{
  return "n:" + n + ":d:" + decimals + ":b:" + nbase;
}

Using that same piece of code also reveals what I believe are the fundamental flaws. Apply a simple algorithm until we have the number of decimals we are asked to provide. Disregarding anything about the precision of the numbers involved and truncation errors in the calculation!

In the instructions (13, 3, Pi) => "103.010" - computing backwards using elementary algebra, we find that "103.010" => 3 + 1/Pi^2 + Pi^2 = 12.96449704 (10 digits of precision).

Simple rounding yields Round("103.0102") = "103.011", and computing backwards we get "103.011" => 3 + 1/Pi^3 + 1/Pi^2 + Pi^2 = 13.00317712 (10 digits of precision).

One interesting test case is the following

Test012
  Expected string length 6 but was 22. Strings differ at index 0.
  Expected: "0.3141"
  But was:  "n:0.314159:d:4:base:10"

I can't think of any scientific text that would consider it correct to return "0.3141" if we are asked for 4 decimals after the decimal point unless a considerable truncation (error) took place - what happened to "0.3142"?

Another interesting test case is

Test03
  Expected string length 10 but was 11. Strings differ at index 4.
  Expected: "36694.0000"
  But was:  "36693.CCCCC"

Rounding 36693.CCCCC to 4 decimals would give the correct result. However considering rounding makes most of the other test cases fail.
My current solution applies a small hack to get the result correct for (100000, 4, 13), but in order to satisfy the other test cases my solution is ultimately incorrect, e.g. it doesn't consider precision/rounding and it cannot handle a test case where the conversion yields 9.95 (nbase 10, decimal 1) and the expected result is 10.00.

Finally, in C#, naming guidelines (e.g. https://msdn.microsoft.com/en-us/library/ms229043(v=vs.110).aspx) recommend that Pascal case be used for method names, i.e. Converter.converter is a violation of that - perhaps 'Convert' instead of 'converter'