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();
У меня есть тестовая обвязка. В страшных случаях - как попытка протестировать статическую функцию, я использую:
#include "code_under_test.c"
...test framework...
таким образом, я включаю весь файл, содержащий функцию под тестом в тестовой обвязке. Это - последнее средство - но это работает.
Можно ли дать больше информации относительно того, почему Вы не можете вызвать функцию?
это не доступный, потому что это является частным в.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() ...
статические функции являются по существу функциями помощника общественности (т.е. представленный) функции. Так IMO, Ваши модульные тесты должны назвать открытый интерфейс с исходными данными, которые осуществляют все пути в статической функции.
вывод (возвращаемые значения / побочные эффекты) государственной функции должен использоваться для тестирования эффекта помех.
Это означает, что у Вас должны быть соответствующие тупики, чтобы 'поймать' эти побочные эффекты. (например, если файл вызовов функции IO, необходимо обеспечить тупики для переопределения, они регистрируют функции lib IO). Лучший способ сделать это путем создания каждого набора тестов отдельным проектом/исполняемым файлом и постараться не связываться с любыми внешними функциями lib. Можно дразнить даже C функции, но это не стоит усилия.
Так или иначе, это - подход, который я использовал до сих пор, и он работает на меня. Удача
Вы могли добавить нестатическую функцию для вызывания статической функции, затем вызвать нестатическую функцию.
static int foo ()
{
return 3;
}
#ifdef UNIT_TEST
int test_foo ()
{
if (foo () == 3)
return 0;
return 1;
}
#endif
Нет - Вы не можете непосредственно протестировать статическую функцию, не изменяя источник, по крайней мере, немного (который является определением помех в 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);
}
Мы обычно не тестируем наши статические функции непосредственно, а скорее удостоверяемся, что логика, которую они выполняют, соответственно тестируется различными тестами функции вызова.
Для модульных тестов у нас на самом деле есть тестовый код в самом исходном файле, и мы условно компилируем его в при тестировании. Это предоставляет полный доступ модульных тестов ко всем функциям и переменным уровня файла (статичный или иначе).
сами модульные тесты не статичны - это позволяет нам называть модульные тесты от единственной супертестовой программы который модульные тесты все единицы компиляции.
, Когда мы поставляем код, мы условно компилируем модульные тесты, но это не на самом деле необходимо (если Вы хотите быть уверенными, что Вы поставлетесь точно тот же код, который Вы протестировали).
Мы всегда находили это неоценимым, чтобы иметь модульные тесты в том же месте как код, который Вы тестируете, так как это делает это более очевидным, что необходимо обновить тесты, если и когда код изменяется.