какова лучшая практика? вызовите функцию, затем возвращаются, если Вы тестируете на что-то, или тест для чего-то затем звонит?
я предпочитаю тест в функции, потому что это делает более легкий просмотр того, какие функции вызваны.
например:
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
?
что лучше?
спасибо
Я чувствую, что тестирование внутри функции лучше. Если вы тестируете вне функции, вам придется тестировать везде, где эта функция может быть вызвана (и это вызовет много дублирования кода).
Приятнее, чтобы все было в одном месте, а затем разбросано повсюду.
Если метод абсолютно требует выполнения определенного условия, прежде чем он сможет выполнить свою функцию, тогда да, вы должны поместить проверку внутри этой функции. Если, с другой стороны, ваш вызывающий код говорит: «Выполняйте эту операцию только при этом наборе условий», тогда условие лучше в вызывающем коде, потому что в следующий раз, когда вы захотите вызвать этот метод, вы можете не захотеть включать это условие. .
В этом случае я чувствую, что имя функции подразумевает, что что-то произойдет с URL-адресом в каждом случае. Кто-то может захотеть вызвать FixURLCosmetics
на странице без GET и ожидать, что что-то произойдет.
Я бы переименовал FixURLCosmetics
в FixGETURLCosmetics
. Затем вызовите исключение, если оно вызывается на странице, отличной от GET.
На вашем месте я бы тестировал в ОБОИХ местах, находясь снаружи и внутри, и высмеивая внутренние компоненты, которые вызываются (например, вызовы context.Request), чтобы усилить внутреннее поведение, а также высмеивая некоторые неожиданные возвраты и то, как ваш метод работает с ними.
В этом случае API, такой как easymock, может значительно упростить процесс подражания внутренним компонентам.