Необходимо протестировать "каждый нетривиальный блок кода" использование модульных тестов в максимально возможной степени.

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

Ваш Проходить проверку подлинности () и Сохраняют (), методы похожи на хороших кандидатов на тестирование.

Даже доберитесь / набор может иметь нечетные последствия, в зависимости от того, как они были реализованы, таким образом, их нужно рассматривать как методы.

Каждый тест их должен будет указать наборы параметров для свойств, определяя и приемлемые и недопустимые свойства для обеспечения возврата вызовов / сбой ожидаемым способом.

Также необходимо знать о глюках безопасности как Внедрение SQL в качестве примера и тест для них.

Таким образом да, действительно необходимо волноваться о тестировании свойств.

Не тестируйте, очевидно, рабочий (шаблон) код. Таким образом, если Ваши методы set и методы считывания просто "propertyvalue =, значение" и "возвращает propertyvalue", не имеет никакого смысла тестировать его.

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

Запись тестов впоследствии является намного более болезненной, но выполнимой.

Вот то, что я сделал бы в Вашем положении:

1. Запишите основной набор тестов, которые тестируют базовую функцию.
2. Получите NCover и выполните его на своих тестах. Ваше тестовое покрытие, вероятно, составит приблизительно 50% в этой точке.
3. Продолжайте добавлять тесты, которые покрывают Ваши пограничные случаи, пока Вы не получаете покрытие приблизительно 80%-90%

Это должно дать Вам хороший рабочий набор модульных тестов, которые будут действовать как хороший буфер против регрессий.

Единственная проблема с этим подходом состоит в том, что код должен быть разработан, чтобы быть тестируемым этим способом. Если Вы сделали какие-либо ошибки связи вначале, Вы не сможете получить высокое покрытие очень легко.

Поэтому действительно важно записать тесты перед написанием кода. Это вынуждает Вас написать код, который слабо связывается.

Я записал бы тест для чего-либо, что Вы - написание кода для этого, является тестируемым за пределами графического интерфейса.

Как правило, любая логика, что я пишу это, имеет любую бизнес-логику, которую я помещаю в другом уровне или слое бизнес-логики.

Затем при записи тестов для чего-либо, что, что-то легко сделать.

Первичная обработка, запишите модульный тест на каждый открытый метод в Вашем "Слое Бизнес-логики".

Если у меня был класс как это:

   public class AccountService
    {
        public void DebitAccount(int accountNumber, double amount)
        {

        }

        public void CreditAccount(int accountNumber, double amount)
        {

        }

        public void CloseAccount(int accountNumber)
        {

        }
    }

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

   [TestFixture]
    public class AccountServiceTests
    {
        [Test]
        public void DebitAccountTest()
        {

        }

        [Test]
        public void CreditAccountTest()
        {

        }

        [Test]
        public void CloseAccountTest()
        {

        }
    }

Запишите свои тесты для проверки кода, который Вы написали, чтобы сделать что-то. Если Вы выполняющий итерации по набору вещей и изменяющий что-то о каждом из них, пишете тест, который делает то же самое и Утверждает, что на самом деле произошел.

Существует много других подходов, которые можно проявить, а именно, Behavoir управляемая разработка (BDD), это более включено и не великолепное место для запуска с навыков поблочного тестирования.

Так, мораль истории, протестируйте что-либо, что делает что-либо, по поводу чего Вы могли бы быть взволнованы, сохранить модульные тесты, тестирующие определенные вещи, которые являются маленькими в размере, много тестов хорошо.

Сохраните свою бизнес-логику за пределами уровня User Interface так, чтобы можно было легко записать тесты для них, и Вы будете хороши.

Я рекомендую TestDriven. Сеть или ReSharper, поскольку оба легко интегрируются в Visual Studio.

Я полагаю, что глупо протестировать методы считывания и методы set, когда они только делают простую операцию. Лично я не пишу тесты комплексной единицы для покрытия любого шаблона использования. Я пытаюсь записать достаточно тестов, чтобы гарантировать, что я обработал нормальное поведение при выполнении и столько же ошибочных случаев, о которых я могу думать. Я запишу больше модульных тестов как ответ на отчеты об ошибках. Я использую модульный тест, чтобы гарантировать, что код отвечает требованиям и сделать будущую модификацию легче. Я чувствую себя намного более готовым изменить код, когда я знаю, что, если я повреждаю что-то, тест перестанет работать.

Пока возможно правильно предположить, где для Вашего кода нужно тестирование, я обычно думаю, что Вам нужны метрики для резервного копирования этого предположения. Поблочное тестирование, по моему мнению, идет рука об руку с метриками покрытия кода.

Код с большим количеством тестов, но маленького покрытия не был хорошо протестирован. Тем не менее код с 100%-м покрытием, но не тестированием граничных и ошибочных случаев является также не большим.

Вы хотите баланс между высоким покрытием (90%-й минимум) и данными ввода переменной.

Не забудьте тестировать на "мусор в"!

Кроме того, модульный тест не является модульным тестом, если он не проверяет на отказ. Модульные тесты, которые не имеют, утверждают или отмечены за известными исключениями, просто протестирует это, код не умирает, когда выполнено!

Необходимо разработать тесты так, чтобы они всегда сообщали об отказах или неожиданных/нежелательных данных!

Это делает наш код лучше... периодом!

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

В истинном духе для поблочного тестирования эти тесты не должны, прежде всего, там "тестировать" больше нашего кода; или получить на 90%-100% лучшее покрытие кода. Это все дополнительные льготы записи тестов сначала. Большая выплата - то, что наше производство кодирует концы быть быть записанным намного лучше из-за естественного процесса TDD.

Чтобы помочь лучше выразить эту мысль, следующее может быть полезным в чтении:

Дефектная теория модульных тестов
Целеустремленная разработка программного обеспечения

Если мы чувствуем, что действие записи большего количества модульных тестов - то, что помогает нам получить более высокий качественный продукт, то мы можем страдать от Грузового Культа Разработки через тестирование.

Я рекомендовал бы писать несколько тестов для Вашего Проходить проверку подлинности и Сохранил бы методы. В дополнение к случаю успеха (где все параметры обеспечиваются, все правильно записано, и т.д.), хорошо иметь тесты для различных случаев возникновения отказов (неправильные или недостающие параметры, недоступные соединения с базой данных если применимо, и т.д.). Я рекомендую Прагматическое Поблочное тестирование в C# с NUnit как ссылка.

Как другие заявили, модульные тесты на методы считывания и методы set являются излишеством, если нет условная логика в Ваших методах считывания и методах set.

Я не протестировал бы фактическую установку свойств. Я был бы более обеспокоен тем, как те свойства заполняются потребителем, и с чем они заполняют их. С любым тестированием необходимо взвесить риски со временем/стоимостью тестирования.

Лично я "протестировал бы что-либо, что может повредиться", и простой метод считывания (или еще лучшие автоматические свойства) не повредятся. Я никогда не имел простого сбоя оператора возврата и для этого никогда не имею тест для них. Если бы методы считывания имеют вычисление в них или некоторой другой форме операторов, я, конечно, добавил бы тесты для них.

Лично я использую Moq в качестве платформы фиктивного объекта и затем проверяю, что мои вызовы объектов окружающие объекты путем он должен.

Действительно тривиальный код как методы считывания и методы set, которые не имеют никакого дополнительного поведения, чем установка частного поля, является излишеством для тестирования. В 3.0 C# даже имеет немного синтаксического сахара, где компилятор заботится о частном поле, таким образом, Вы не должны программировать это.

Я обычно пишу много очень простых тестов, проверяющих поведение, которое я ожидаю от своих классов. Даже если это - простой материал как добавление двух чисел. Я переключаюсь много между записью простого теста и записью некоторых строк кода. Причина этого состоит в том, что я затем могу переехать код, не будучи боящимся, что я повредил вещи, о которых я не думал.

Правило состоит в том, что необходимо протестировать каждую часть логики, которую Вы пишете. Если Вы реализовали некоторую определенную функциональность в методах считывания и методах set, я думаю, что их стоит протестировать. Если они только присваивают значения некоторым частным полям, не беспокоиться.

Если они действительно тривиальны, то не потрудитесь тестировать. Например, если они реализованы как это;

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }
}

Если с другой стороны, Вы делаете что-то умное, (как шифрование и дешифрование пароля в методе считывания/методе set) затем дают ему тест.

Необходимо покрыть осуществление каждого метода класса с UT и проверить возвращаемое значение метода. Это включает методы считывания и методы set, особенно в случае, если участники (свойства) являются сложными классами, который требует выделения памяти большой емкости во время их инициализации. Назовите метод set с некоторой очень большой строкой, например (или что-то с греческими символами) и проверьте, что результат корректен (не усеченный, кодирование является хорошим e.t.c.)

В случае простых целых чисел, который также применяет - что происходит, если Вы передаете долго вместо целого числа? Это - причина, для которой Вы пишете UT :)

Другой канонический ответ. Это, я верю от Ron Jeffries:

Только протестируйте код, что Вы хотите работать.

Тестирование шаблонного кода является пустой тратой времени, но поскольку Slavo заявляет, если Вы добавляете побочный эффект к своим методам считывания/методам set, затем необходимо записать тест для сопровождения той функциональности.

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

Я протестировал бы Ваши методы считывания и методы set. В зависимости от того, кто пишет код, некоторые люди изменяют значение метода считывания/методов установщика. Я видел переменную инициализацию и другую проверку как часть методов получателя. Для тестирования этого вида вещи Вы хотели бы модульные тесты, покрывающие тот код явно.

Это получило меня в поблочное тестирование, и оно сделало меня очень счастливым

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

Затем мы должны были переписать важную часть кода в нашей бухгалтерской программе. Эта часть была очень сложна, поскольку она включила много различных сценариев. Часть, о которой я говорю, является методом для оплаты продаж, и/или счета покупки уже ввели в систему учета.

Я просто не знал, как начать кодировать его, поскольку было столько различных способов оплаты. Счет мог составить 100$, но клиент только передал 99$. Возможно, Вы отправили счета продаж клиенту, но Вы также купили от того клиента. Таким образом, Вы продали его за 300$, но Вы купили за 100$. Можно ожидать, что клиент заплатит Вам 200$ для урегулирования баланса. И что, если Вы продали за 500$, но клиент платит Вам только 250$?

Таким образом, у меня была очень сложная проблема для решения со многими возможностями, что один сценарий будет работать отлично, но был бы неправильным в другом типе invocie/payment комбинации.

Это - то, где поблочное тестирование пришло на помощь.

Я начал писать (в тестовом коде) метод для создания списка счетов, и для продаж и для покупок. Затем я записал второй метод для создания фактической оплаты. Обычно пользователь ввел бы ту информацию через пользовательский интерфейс.

Затем я создал первый TestMethod, тестируя очень простую оплату единственного счета без любых платежных скидок. Все действие в системе произошло бы, когда bankpayment будет сохранен к базе данных. Поскольку Вы видите, что я создал счет, создал оплату (банковская сделка) и сохранил транзакцию на диск. В моем утверждает, что я поместил то, что должно быть корректными числами, заканчивающимися в Банковской сделке и в связанном Счете. Я проверяю на количество платежей, сумм платежей, суммы скидки и баланса счета после транзакции.

После того, как тест работал, я перешел бы к базе данных и проверил бы дважды, если бы то, что я ожидал, было там.

После того, как я записал тест, я начал кодировать способ оплаты (часть класса BankHeader). В кодировании я только потрудился кодом делать первую тестовую передачу. Я еще не думал о другом, более сложном, сценарии.

Я запустил первый тест, исправил небольшую ошибку, пока мой тест не передаст.

Затем я начал писать второй тест, на этот раз работая с платежной скидкой. После того, как я записал тест, я изменил способ оплаты для поддержки скидок.

При тестировании на правильность с платежной скидкой я также протестировал простую оплату. Оба теста должны передать, конечно.

Затем я проложил себе путь вниз к более сложным сценариям.

1) Думайте о новом сценарии

2) Запишите тест для того сценария

3) Запущенный, что единственный тест, чтобы видеть, передало ли это

4) Если бы это не сделало то я отладил бы и изменил бы код, пока это не передало бы.

5) При изменении кода я продолжил запускать все тесты

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

Я уверен, что использование поблочного тестирования сохранило меня несколько дней (или недели) кодирования и более или менее гарантирует правильность моего метода.

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

Да, даже протестированный код может все еще иметь ошибки, если пользователь делает вещи, Вы не думали или препятствовали тому, чтобы он делал

Ниже просто некоторые тесты, которые я создал для тестирования моего способа оплаты.

public class TestPayments
{
    InvoiceDiaryHeader invoiceHeader = null;
    InvoiceDiaryDetail invoiceDetail = null;
    BankCashDiaryHeader bankHeader = null;
    BankCashDiaryDetail bankDetail = null;



    public InvoiceDiaryHeader CreateSales(string amountIncVat, bool sales, int invoiceNumber, string date)
    {
        ......
        ......
    }

    public BankCashDiaryHeader CreateMultiplePayments(IList<InvoiceDiaryHeader> invoices, int headerNumber, decimal amount, decimal discount)
    {
       ......
       ......
       ......
    }


    [TestMethod]
    public void TestSingleSalesPaymentNoDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 1, "01-09-2008"));
        bankHeader = CreateMultiplePayments(list, 1, 119.00M, 0);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(1, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(119M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(0M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
    }

    [TestMethod]
    public void TestSingleSalesPaymentDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 2, "01-09-2008"));
        bankHeader = CreateMultiplePayments(list, 2, 118.00M, 1M);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(1, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(118M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(1M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
    }

    [TestMethod]
    [ExpectedException(typeof(ApplicationException))]
    public void TestDuplicateInvoiceNumber()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("100", true, 2, "01-09-2008"));
        list.Add(CreateSales("200", true, 2, "01-09-2008"));

        bankHeader = CreateMultiplePayments(list, 3, 300, 0);
        bankHeader.Save();
        Assert.Fail("expected an ApplicationException");
    }

    [TestMethod]
    public void TestMultipleSalesPaymentWithPaymentDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 11, "01-09-2008"));
        list.Add(CreateSales("400", true, 12, "02-09-2008"));
        list.Add(CreateSales("600", true, 13, "03-09-2008"));
        list.Add(CreateSales("25,40", true, 14, "04-09-2008"));

        bankHeader = CreateMultiplePayments(list, 5, 1144.00M, 0.40M);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(4, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(118.60M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(400, bankHeader.BankCashDetails[0].Payments[1].PaymentAmount);
        Assert.AreEqual(600, bankHeader.BankCashDetails[0].Payments[2].PaymentAmount);
        Assert.AreEqual(25.40M, bankHeader.BankCashDetails[0].Payments[3].PaymentAmount);

        Assert.AreEqual(0.40M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[2].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[3].PaymentDiscount);

        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[2].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[3].InvoiceHeader.Balance);
    }

    [TestMethod]
    public void TestSettlement()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("300", true, 43, "01-09-2008")); //Sales
        list.Add(CreateSales("100", false, 6453, "02-09-2008")); //Purchase

        bankHeader = CreateMultiplePayments(list, 22, 200, 0);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(2, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(300, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(-100, bankHeader.BankCashDetails[0].Payments[1].PaymentAmount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].InvoiceHeader.Balance);
    }

Не повреждает писать модульные тесты на Ваши методы считывания и методы set. Прямо сейчас они могут просто делать поле, get/sets под капотом, но в будущем у Вас может быть логика проверки или зависимости межсвойства, которые должны быть протестированы. Легче записать это теперь, в то время как Вы думаете об этом затем не забывающий модифицировать его, если то время когда-нибудь настает.

Необходимо протестировать все. Прямо сейчас у Вас есть методы считывания и методы set, но однажды Вы могли бы изменить их несколько, возможно, чтобы сделать проверку или что-то еще. Тесты, которые Вы пишете сегодня, будут использоваться завтра, чтобы удостовериться, что все продолжает работать, как обычно. Когда Вы тест записи, необходимо забыть соображения как, "прямо сейчас это тривиально". В гибком или контексте, на котором делают пробную поездку, необходимо протестировать рефакторинг будущего принятия. Кроме того, Вы пытались включить действительно странные значения как чрезвычайно длинные строки или другое "плохое" содержание? Хорошо Вы никогда не должны... принимать, как плохо Вашим кодом можно злоупотребить в будущем.

Обычно я нахожу, что запись обширных пользовательских тестов находится на одной стороне, исчерпывая. С другой стороны, хотя это всегда дает Вам неоценимое понимание о том, как Ваше приложение должно работать и помогает Вам выбросить легкий (и ложь) предположения (как: имя пользователя всегда будет меньше чем 1 000 символов в длине).

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

В иерархиях наследования удостоверьтесь, что протестировали на соответствие LSP.

Тестирование методов считывания по умолчанию и методов set не кажется очень полезным для меня, если Вы не планируете сделать некоторую проверку позже.

Поскольку я понимаю модульные тесты в контексте гибкой разработки, Mike, да, необходимо протестировать методы считывания и методы set (предполагающий, что они публично видимы). Целое понятие поблочного тестирования состоит в том, чтобы протестировать программный блок, который является классом в этом случае как черный квадрат. Так как методы считывания и методы set внешне видимы, необходимо протестировать их наряду с, Аутентифицируют и Сохраняют.

хорошо, если Вы думаете, что это может повредиться, записать тест для него. Я обычно не тестирую метод set/метод считывания, но позволяет, говорит, что Вы делаете один для Пользователя. Имя, которые связывают имя и фамилию, я записал бы тест поэтому, если бы кто-то изменяет порядок на фамилию и имя, по крайней мере, он знал бы, что изменил что-то, что было протестировано.

Канонический ответ является "тестом что-либо, что может возможно повредиться". Если Вы уверены, что свойства не повредятся, не тестируйте их.

И после того как что-то, как находят, повредилось (Вы находите ошибку), очевидно, это означает, что необходимо протестировать его. Запишите тест, чтобы воспроизвести ошибку, наблюдать, что она перестала работать, затем исправляет ошибку, затем наблюдает тестовую передачу.

Если Аутентифицирование и Сохранит использование методов свойства, то Ваши тесты косвенно коснутся свойств. Пока свойства просто обеспечивают доступ к данным, затем явное тестирование не должно быть необходимым (если Вы не идете для 100%-го покрытия).

Для простых модулей, которые могут закончиться в инструментарии, или в типе с открытым исходным кодом проекта, необходимо протестировать как можно больше включая тривиальные методы считывания и методы set. Вещь, которую Вы хотите иметь в виду, состоит в том, что, генерируя модульный тест, как Вы пишете, конкретный модуль является довольно простым и прямым. Добавление методов считывания и методов set является минимальным кодом и может быть обработано без очень мысли. Однако, после того как Ваш код помещается в большую систему, это дополнительное усилие может защитить Вас от изменений в базовой системе, таких как изменения типа в базовом классе. Тестирование всего является лучшим способом иметь регрессию, которая завершена.

Протестируйте свой код, не язык.

Модульный тест как:

Integer i = new Integer(7);
assert (i.instanceOf(integer));

только полезно, если Вы пишете компилятор и существует ненулевой шанс что Ваш instanceof метод не работает.

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

Тестирование класса должно проверить что:

1. методы и свойства возвращают математические ожидания
2. Соответствующие excepts брошены, когда недействительный аргумент предоставляется
3. Взаимодействия между классом и другими объектами происходят как ожидалось, когда данный метод называют

Конечно, если методы считывания и методы set не имеют никакой специальной логики затем, тесты Аутентифицирования andSave методы должны покрыть их, но иначе тест explict должен быть записан