Если вы хотите временно установить параметры для отображения одного большого DataFrame, вы можете использовать option_context :
with pd.option_context('display.max_rows', -1, 'display.max_columns', 5):
print df
Значения параметров автоматически восстанавливаются при выходе из блока with
.
Единственный способ проверить изменение постоянного (!) Значения - сделать эту константу настройкой приложения
Все варианты использования, которые вы указали в вопросе, звучат как настройки приложения, не константы, для меня. Константа - это значение, которое, в общем, является постоянным, например:
const decimal LITERS_PER_HOGSHEAD = 238.480942392;
Отредактировано для добавления: Надеюсь, это более полезно, чем мой легкомысленный ответ. Обычно я создаю класс AppSettings. Некоторые свойства этого класса извлекаются из файла конфигурации, некоторые - это настройки, которые я не ожидаю изменить, а некоторые могут быть константами.
public class AppSettings
{
public const decimal GILLS_PER_HOMER = 1859.771248601;
public string HelpdeskPhone
{
get { // pulled from config and cached at startup }
}
public int MaxNumberOfItemsInAComboBox
{
get { return 3; }
}
}
Судя по тому, что я прочитал о вашем вопросе, это не имеет ничего общего с TDD. Описываемое вами использование не является настоящей константой, а скорее значением конфигурации, поэтому в этих случаях вам не следует использовать модификатор const
.
Есть два вида констант:
При написании кода с использованием TDD каждая строка производственного кода должна существовать, потому что сначала произошла ошибка теста это потребовало написания этого кода. А по мере рефакторинга кода некоторые магические значения будут преобразованы в константы. Некоторые из них также могут быть хороши в качестве настроек приложения, но для удобства (меньше кода) они были настроены в коде, а не во внешнем файле конфигурации.
В этом случае я пишу тесты, как производственный, так и тестовый код будут использовать те же константы. В тестах будет указано, что константы используются должным образом. Но тесты не будут повторять значение константы, например, в « assert MAX_ITEMS == 4
», потому что это будет дублированный код. Вместо, тесты будут проверять, что некоторое поведение правильно использует константы.
Например, здесь - это пример приложения (написанного мной), которое будет печатать Longcat указанной длины. Как видите, Longcat определяется как серия констант:
public class Longcat {
// Source: http://encyclopediadramatica.com/Longcat
public static final String HEAD_LINES = "" +
" /\\___/\\ \n" +
" / \\ \n" +
" | # # | \n" +
" \\ @ | \n" +
" \\ _|_ / \n" +
" / \\______ \n" +
" / _______ ___ \\ \n" +
" |_____ \\ \\__/ \n" +
" | \\__/ \n";
public static final String BODY_LINE = "" +
" | | \n";
public static final String FEET_LINES = "" +
" / \\ \n" +
" / ____ \\ \n" +
" | / \\ | \n" +
" | | | | \n" +
" / | | \\ \n" +
" \\__/ \\__/ \n";
...
Тесты проверяют, что константы используются правильно, но они не дублируют значение константы. Если я изменю значение константы, все тесты автоматически будут использовать новое значение. (И правильно ли выглядит изображение Longcat ASCII, его необходимо проверить вручную. Хотя вы даже можете автоматизировать это с помощью приемочного испытания, которое было бы рекомендовано для более крупного проекта.)
public void test__Longcat_with_body_size_2() {
Longcat longcat = factory.createLongcat(2);
assertEquals(Longcat.BODY_LINE + Longcat.BODY_LINE, longcat.getBody());
}
public void test__Fully_assembled_longcat() {
Longcat longcat = factory.createLongcat(2);
assertEquals(Longcat.HEAD_LINES + longcat.getBody() + Longcat.FEET_LINES, longcat.toString());
}
То же самое В приложении также есть некоторые константы, которые никогда не будут изменены, например соотношение между метрами и футами. Эти значения могут / должны быть жестко закодированы в тесте:
public void test__Identity_conversion() {
int feet1 = 10000;
int feet2 = FEET.from(feet1, FEET);
assertEquals(feet1, feet2);
}
public void test__Convert_feet_to_meters() {
int feet = 10000;
int meters = METERS.from(feet, FEET);
assertEquals(3048, meters);
}
public void test__Convert_meters_to_feet() {
int meters = 3048;
int feet = FEET.from(meters, METERS);
assertEquals(10000, feet);
}
И производственный код выглядит так:
public enum LengthUnit {
METERS("m", 1.0), FEET("ft", 0.3048), PETRONAS("petronas", 451.9), LINES("lines", 0.009);
private final String name;
private final double lengthInMeters;
...
public int from(int length, LengthUnit unit) {
return (int) (length * unit.lengthInMeters / this.lengthInMeters);
}
}
Обратите внимание, что я не писал никаких тестов для высоты башен-близнецов Петронас , потому что это информация является декларативной (а декларативные данные редко ломаются), и я уже написал тесты для логики преобразования (см. выше). Если будут добавлены другие похожие константы (Эйфелева башня, Эмпайр-стейт-билдинг и т. Д.), Они будут автоматически обнаружены приложением и будут работать должным образом.
Это потому, что все эти вещи не постоянные ... Фактические вещи:
Если что-то из этого когда-либо изменится, не волнуйтесь,
Пара вещей.
] Во-первых, TDD и развивающийся дизайн, который продвигает TDD, - это разделение ваших обязанностей, применение DRY и внедрения зависимостей.
Модульное тестирование константы легко и, возможно, немного бессмысленно.
Но тестировать вычисление этой константы другим модулем, на мой взгляд, не является модульным тестом . Это интеграционный тест . Проверка значения const в других единицах измерения может быть покрыта имитацией или заглушкой.
Во-вторых, ваши примеры разнообразны:
Вы регистрируете пример, используя только 1 файл. Просто существует 2. если требовалось, чтобы существовал только один файл, вы могли бы изготовить для этого тест.
Тестирование тайм-аута транзакции должно выполняться интеграционным тестом. Он должен показать, что ваш исходный тест не в том, в чем проблема.
Изменение CompanyName - это нормально, поскольку оно связано с названием компании. Доменное имя должно и могло быть другим const.
Мне кажется, что вы используете константы в основном для иллюстрации параметров конфигурации. Это идеально подходит для ConfigurationManager, но может быть трудно использовать и для тестирования.
Я бы рекомендовал следующее использование:
const String SomeValue = "TESTCONSTANT";
static class ConfigurationSettings
{
static String SomeProperty
{
get
{
var result = SomeValue;
if (ConfigurationManager.AppSettings["SOMEKEY"] != null)
result = ConfigurationManager.AppSettings["SOMEKEY"];
return result;
}
}
}