Лучше ли тестировать, нужна ли функция внутри или снаружи?
Какова наилучшая практика? вызывать функцию, а затем возвращать, если вы что-то проверяете, или проверить что-нибудь, а затем позвонить?
Я предпочитаю тест внутри функции, потому что он облегчает просмотр функций, которые вызываются.
например:
protected void Application_BeginRequest(object sender, EventArgs e)
{
this.FixURLCosmetics();
}
и
private void FixURLCosmetics()
{
HttpContext context = HttpContext.Current;
if (!context.Request.HttpMethod.ToString().Equals("GET", StringComparison.OrdinalIgnoreCase))
{
// if not a GET method cancel url cosmetics
return;
};
string url = context.Request.RawUrl.ToString();
bool doRedirect = false;
// remove > default.aspx
if (url.EndsWith("/default.aspx", StringComparison.OrdinalIgnoreCase))
{
url = url.Substring(0, url.Length - 12);
doRedirect = true;
}
// remove > www
if (url.Contains("//www"))
{
url = url.Replace("//www", "//");
doRedirect = true;
}
// redirect if necessary
if (doRedirect)
{
context.Response.Redirect(url);
}
}
это хорошо:
if (!context.Request.HttpMethod.ToString().Equals("GET", StringComparison.OrdinalIgnoreCase))
{
// if not a GET method cancel url cosmetics
return;
};
или если это нужно сделать в Application_BeginRequest
?
что лучше?
Thnx
Ответы
Ответ 1
Мне кажется, что тестирование внутри функции лучше. Если вы тестируете вне функции, вам придется тестировать всюду, что функция может быть вызвана (и вызовет много дубликатов кода).
Лучше иметь все в одном месте, а затем распространяться повсюду.
Ответ 2
Если метод абсолютно требует выполнения определенного условия, прежде чем он сможет выполнить свою функцию, тогда да, вы должны поместить проверку внутри этой функции. Если, с другой стороны, ваш код вызова говорит "выполнять эту операцию только в этом наборе условий", тогда условие лучше в вызывающем коде, потому что в следующий раз, когда вы хотите вызвать этот метод, вы можете не захотеть включить это условие.
Ответ 3
В этом случае я чувствую, что имя функции подразумевает, что что-то произойдет с URL-адресом в каждом случае. Кто-то может захотеть вызвать FixURLCosmetics
на странице без GET и ожидать, что что-то произойдет.
Я бы переименовал FixURLCosmetics
в FixGETURLCosmetics
. Затем выведите исключение, если оно вызвало страницу не-GET.
Ответ 4
Если бы я был вами, я бы тестировал в BOTH местах, находясь вне AND внутри и издеваясь над внутренними компонентами, которые вызываются (например, вызовы context.Request), чтобы усилить внутреннее поведение, а также высмеивать некоторые неожиданные возвращения и как ваш метод работает с ними.
В этом случае API, такой как easymock, может упростить LOT издевательство над внутренними компонентами.