Prefer simplicity over testability? Currently I try to create some unit tests for a project, which provides access to some webservice methods.

It's interface is rather simple. I have a class "WebService" which offers methods like "CreatePDF".
Here's a little example:

The Model:
The model contains a number of properties, which each represent a URL parameter of the webservice. The models provide a method "GetParameterDictionary", which delivers a dictionary with key == url parameter name and value == url parameter value.

public class CreatePDFParameters
{
        public List&lt;string&gt; Names { get; set; }
        public List&lt;string&gt; Colors { get; set; }

        public Dictionary&lt;string, string&gt; GetParameterDictionary()
        {
            [...] //returns Key == url parameter name and Value == ";" separated list of values
        }
}


So here's a example for the Interface method:

public byte[] CreatePDF(CreatePDFParameters parameters)
{
    return MakeByteRequest(GetQuery(WebServiceMethods.CreatePDF, parameters.GetParameterDictionary()));
}

/// &lt;summary&gt;
///     Creates a query out of a dictionary. The dictionary must have the paramname as key and the value as value!
/// &lt;/summary&gt;
private string GetQuery(string methodName, Dictionary&lt;string, string&gt; parameters)
{
    string parameterString = parameters.Where(parameter =&gt; !String.IsNullOrEmpty(parameter.Value))
    .Aggregate(String.Empty, (current, parameter) =&gt; String.Format(String.IsNullOrEmpty(current) ? "{0}?{1}={2}" : "{0}&amp;{1}={2}", current, parameter.Key, parameter.Value));
    return methodName + parameterString;
}


As you can see, you only need to call the CreatePDF method with a parameters object. The method itself calls a methods, which creates the query and calls a method, which makes the actual request (It calls directly the ByteRequest method, there are methods like StringRequest (delivers a string as return value) too).

I would like to write a UnitTest for the GetQuery method. But I don't want to make it public or internal in the actual state. I could make the method public If I would remove the "CreatePDF" method and let the user make direkt calls to MakeByteRequest / GetQuery and so on - which would require the users to have some knowledge about the webservice itself (knowledge about return types, web method names and so on).

Would you prefer a more simple "interface" over unit tests in this case?
The WebService interface with a CreatePDF method is good like that.
The private GetQuery method is an implementation detail that should not be exposed.

But there's something else you can do to test GetQuery.
You can move that logic outside to a different class,
whose main responsibility will be to build query strings.
Then the method will be public, naturally, and you can implement unit tests for it.

The query string builder class can become a collaborator of WebService:
implementations of WebService can call it from their GetQuery methods to build query strings correctly,
with the comforting thought that the utility class is properly unit tested.