Как проверить статическую функцию

2012 Это лучшее решение для этого сценария (проверено с помощью Visual & nbsp; Studio & nbsp; 2008 ):

Configuration config = WebConfigurationManager.OpenWebConfiguration(HttpContext.Current.Request.ApplicationPath);
config.AppSettings.Settings.Remove("MyVariable");
config.AppSettings.Settings.Add("MyVariable", "MyValue");
config.Save();

Обновление 2018 => Протестировано против 2015 г. - Asp. net MVC5

var config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
config.AppSettings.Settings["MyVariable"].Value = "MyValue";
config.Save();

, если вам нужно проверить элемент, используйте этот код:

var config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
if (config.AppSettings.Settings["MyVariable"] != null)
{
config.AppSettings.Settings["MyVariable"].Value = "MyValue";
}
else { config.AppSettings.Settings.Add("MyVariable", "MyValue"); }
config.Save();

37
задан Kevin Yu 27 February 2009 в 03:33
поделиться

6 ответов

У меня есть тестовая обвязка. В страшных случаях - как попытка протестировать статическую функцию, я использую:

#include "code_under_test.c"
...test framework...

таким образом, я включаю весь файл, содержащий функцию под тестом в тестовой обвязке. Это - последнее средство - но это работает.

49
ответ дан Jonathan Leffler 27 February 2009 в 03:33
поделиться
  • 1
    @GotDibbs: Я знаю it' s некоторое время, но here' s jsFiddle, который хорошо работает для меня в IE 9 режимов стандартов: jsfiddle.net/3s7Ly/1 – Tim Down 14 May 2013 в 09:53

Можно ли дать больше информации относительно того, почему Вы не можете вызвать функцию?

это не доступный, потому что это является частным в.c файл? Если так, Вы - лучший выбор, должен использовать условную компиляцию, которая допускает доступ к функции, чтобы позволить, чтобы другие единицы компиляции получили доступ к нему. Например

SomeHeaderSomewher.h

#if UNIT_TEST
#define unit_static 
#else
#define unit_static static
#endif

Foo.h

#if UNIT_TEST
void some_method
#endif

Foo.cpp

unit_static void some_method() ...
13
ответ дан JaredPar 27 February 2009 в 03:33
поделиться

статические функции являются по существу функциями помощника общественности (т.е. представленный) функции. Так IMO, Ваши модульные тесты должны назвать открытый интерфейс с исходными данными, которые осуществляют все пути в статической функции.

вывод (возвращаемые значения / побочные эффекты) государственной функции должен использоваться для тестирования эффекта помех.

Это означает, что у Вас должны быть соответствующие тупики, чтобы 'поймать' эти побочные эффекты. (например, если файл вызовов функции IO, необходимо обеспечить тупики для переопределения, они регистрируют функции lib IO). Лучший способ сделать это путем создания каждого набора тестов отдельным проектом/исполняемым файлом и постараться не связываться с любыми внешними функциями lib. Можно дразнить даже C функции, но это не стоит усилия.

Так или иначе, это - подход, который я использовал до сих пор, и он работает на меня. Удача

5
ответ дан Dushara 27 February 2009 в 03:33
поделиться

Вы могли добавить нестатическую функцию для вызывания статической функции, затем вызвать нестатическую функцию.

static int foo ()
{
   return 3;
}

#ifdef UNIT_TEST
int test_foo ()
{
  if (foo () == 3)
    return 0;

  return 1;
}
#endif
2
ответ дан Paul Beckingham 27 February 2009 в 03:33
поделиться
  • 1
    Конечно, теперь I' m имеющий проблему, выясняющую, как инстанцировать UrlHelper в веб-сервисе, который имеет функцию. Аргумент. – marcel_g 28 July 2009 в 02:35

Нет - Вы не можете непосредственно протестировать статическую функцию, не изменяя источник, по крайней мере, немного (который является определением помех в C - что это нельзя назвать от функции в другом файле).

Вы могли создать отдельную функцию в тестовом файле, который просто вызывает статическую функцию?

, Например:

//Your fn to test
static int foo(int bar)
{
  int retVal;
  //do something
  return retVal;
}

//Wrapper fn
int test_foo(int bar)
{
  return foo(bar);
}

Мы обычно не тестируем наши статические функции непосредственно, а скорее удостоверяемся, что логика, которую они выполняют, соответственно тестируется различными тестами функции вызова.

5
ответ дан Beep beep 27 February 2009 в 03:33
поделиться
  • 1
    Возможно, это было год назад, но рассмотрение исходного кода jQuery ( code.jquery.com/jquery-1.9.1.js ), мне не удается видеть различие от TimDown' s ответ (опускающий некоторую логику обработки ошибок). – Zotov 9 February 2013 в 08:15

Для модульных тестов у нас на самом деле есть тестовый код в самом исходном файле, и мы условно компилируем его в при тестировании. Это предоставляет полный доступ модульных тестов ко всем функциям и переменным уровня файла (статичный или иначе).

сами модульные тесты не статичны - это позволяет нам называть модульные тесты от единственной супертестовой программы который модульные тесты все единицы компиляции.

, Когда мы поставляем код, мы условно компилируем модульные тесты, но это не на самом деле необходимо (если Вы хотите быть уверенными, что Вы поставлетесь точно тот же код, который Вы протестировали).

Мы всегда находили это неоценимым, чтобы иметь модульные тесты в том же месте как код, который Вы тестируете, так как это делает это более очевидным, что необходимо обновить тесты, если и когда код изменяется.

7
ответ дан paxdiablo 27 February 2009 в 03:33
поделиться
  • 1
    jQuery.parseXml может быть довольно медленным. Я предложил бы смотреть на сообщение от @TimDown – GotDibbs 21 August 2012 в 16:08
Другие вопросы по тегам:

Похожие вопросы: