Testowanie internali i privatów

Temat kontrowersyjny, drażliwy, ale my się nie boimy o takich rozmawiać, a więc testowanie wewnętrznych implementacji które raczej nie mają sensu do bycia wyodrębnionymi (tu bardziej te private niż internale)

public class DoSomething
{
	public string PublicAPIDoSomething(string a)
	{
		var temporary = InternalDoSomething1(a);
		return InternalDoSomething2(temporary);
	}

	private string InternalDoSomething2(string temporary)
	{
		return "a";
	}

	internal string InternalDoSomething1(string a)
	{
		return "b";
	}
}

Jakiś lepszy pomysł na dostanie się do w/w metod z poziomu testów poza trikami typu:

[assembly: InternalsVisibleTo("App.Tests")]

lub refleksją?

[Fact]
public void Test1()
{
	var d = new DoSomething();
	var methodInfo = typeof(DoSomething).GetMethod("InternalDoSomething1", BindingFlags.NonPublic | BindingFlags.Instance);
	object[] parameters = { "asd" };
	methodInfo.Invoke(d, parameters);
}

Według mojej najlepszej wiedzy, testowanie prywatnych metod kłóci się z ideą Unit Testów. W Unit testach chodzi przecież o testowanie publicznego API. Na moje, jeżeli zachodzi konieczność testowania prywatnych metod, to występuje jakiś błąd w architekturze.

Natomiast jeżeli już koniecznie musisz, to alternatywą jest stworzenie klasy do Unit Testów, która dziedziczy po klasie z metodami, które chciałby testować.

To wszystko jest ze sobą bardzo sprytnie połączone.

1. Jeśli nie ma sensu wydzielać, to znaczy, że operują na wewnętrznym stanie klasy i nie mają sensu dla nich oddzielne przypadki testowe, bo to, co robią jest zależne od działania reszty kodu tej klasy.
2. Jeśli zaś oddzielne przypadki testowe mają sens, to znaczy, że jest to oddzielna jednostka, i trzeba do niej zrobić jakieś publiczne wejście.