Есть ли какая-либо сериализация Поблочного тестирования точки?

Если формат сериализованного XML имеет значение, вам необходимо протестировать сериализацию. Если важно, чтобы вы могли десериализовать его, вам необходимо протестировать десериализацию.

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

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

Если вы ничего не можете сделать, чтобы изменить способ сериализации вашего класса, тогда вы тестируете реализацию .NET сериализации XML; -)

Если вы хотите убедиться, что сериализация ваших объектов не прерывается, то обязательно используйте модульный тест. Если вы читали документы MSDN для класса XMLSerializer :

XmlSerializer не может сериализовать или десериализовать следующее:

Массивы ArrayList
Массивы списка

Также есть своеобразная проблема с перечислениями, объявленными как беззнаковые длинные. Кроме того, любые объекты, помеченные как [Устаревшие] , не сериализуются с .Net 3.5 и более поздних версий.

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

По сути, вы не выполняете модульное тестирование сериализации XML, вы проверяете возможность сериализации ваших объектов. То же самое касается десериализации.

Я делал это в некоторых случаях ... не тестируя сериализацию как таковую, но используя некоторые «известные хорошие» сериализации XML, а затем загружая их в свои классы и проверяя, что все свойства (если применимо) имеют ожидаемые значения.

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

Для меня это абсолютно из категории «Не беспокойся». Я не тестирую свои инструменты. Однако, если вы написали свой собственный класс сериализации, то непременно выполните его модульное тестирование.

Вам нужна возможность обратной совместимости? Если это так, возможно, стоит создать модульные тесты файлов, созданных старыми версиями, которые должны быть десериализованы новыми версиями.

Кроме этого, если вы когда-нибудь представите что-нибудь «интересное», это может стоит провести модульный тест, чтобы просто проверить, можете ли вы сериализовать и десериализовать, просто чтобы убедиться, что вы не делаете что-то странное со свойством readonly и т. Д.

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

По умолчанию сериализатор XML опускает свойства с нулевым значением, если вы не добавите Атрибут [XmlElement (IsNullable = true)]. Точно так же вам может потребоваться перенаправить общие свойства списка в стандартные массивы с атрибутом XMLArray.

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

Мы делаем приемочное тестирование нашей сериализации, а не модульное тестирование.

Это означает, что наши приемочные тестеры берут схему XML или, как в вашем случае, некоторый образец XML, и воссоздают свой собственный сериализуемый класс передачи данных.

Затем мы используем NUnit для тестирования нашей службы WCF с этим XML для чистой комнаты.

С помощью этой техники мы выявили очень много ошибок. Например, если мы изменили имя члена .NET и забыли добавить тег [XmlElement] со свойством Name = .

I agree with you that you will be testing the .NET implementation more than you'll be testing your own code. But if that's what you want to do (perhaps you don't trust the .NET implementation :) ), I might approach your three questions as follows.

1. Yes, it's certainly possible to test the writer without the reader. Use the writer to serialize the example (20-year old Bob) you provided to a MemoryStream. Open the MemoryStream with an XmlDocument. Assert the root node is named "MyObject". Assert it has one attribute named "Height" with value "300". Assert there is a "Name" element containing a text node with value "Bob". Assert there is an "Age" element containing a text node with value "20".

2. Just do the reverse process of #1. Create an XmlDocument from the 20-year old Bob XML string. Deserialize the stream with the reader. Assert the Name property equals "Bob". Assert the Age property equals 20. You can do things like add test case with insignificant whitespace or single quotes instead of double-quotes to be more thorough.

3. See #1. You can extend it by adding what you consider to be tricky "edge" cases you think could break it. Names with various Unicode characters. Extra long names. Empty names. Negative ages. Etc.

Есть много типов, с которыми не справляется сериализация и т. Д. Также, если у вас неправильные атрибуты, часто возникает исключение. при попытке прочитать xml обратно.

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

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

Как говорили другие люди, если вам нужно иметь возможность считывать данные, сохраненные старыми версиями ваше программное обеспечение, вам лучше сохранить набор примеров файлов данных для каждой поставляемой версии и провести тесты, чтобы убедиться, что вы все еще можете их читать. Это сложнее, чем кажется на первый взгляд, так как значение полей объекта может меняться от версии к версии, поэтому одной возможности создать текущий объект из старого сериализованного файла недостаточно, вы должны проверить, что значение такое же поскольку это была версия программного обеспечения, которое сохранило файл. (Теперь добавьте атрибут версии в корневой объект!)

поэтому я бы не стал делать это для работы с сериализацией.

Как говорили другие люди, если вам нужно иметь возможность считывать данные, сохраненные старыми версиями вашего программного обеспечения, вам лучше сохранить набор примеров файлов данных для каждого отправленного версия и тесты, подтверждающие, что вы все еще можете их читать. Это сложнее, чем кажется на первый взгляд, так как значение полей объекта может меняться от версии к версии, поэтому одной возможности создать текущий объект из старого сериализованного файла недостаточно, вы должны проверить, что значение такое же поскольку это была версия программного обеспечения, которое сохранило файл. (Теперь добавьте атрибут версии в корневой объект!)

поэтому я бы не стал делать это для работы с сериализацией.

Как говорили другие люди, если вам нужно иметь возможность считывать данные, сохраненные старыми версиями вашего программного обеспечения, вам лучше сохранить набор примеров файлов данных для каждого отправленного версия и тесты, подтверждающие, что вы все еще можете их читать. Это сложнее, чем кажется на первый взгляд, так как значение полей объекта может меняться от версии к версии, поэтому одной возможности создать текущий объект из старого сериализованного файла недостаточно, вы должны проверить, что значение такое же поскольку это была версия программного обеспечения, которое сохранило файл. (Теперь добавьте атрибут версии в корневой объект!)

вам лучше сохранить набор примеров файлов данных для каждой поставляемой версии и иметь тесты, чтобы убедиться, что вы все еще можете их читать. Это сложнее, чем кажется на первый взгляд, так как значение полей объекта может меняться от версии к версии, поэтому одной возможности создать текущий объект из старого сериализованного файла недостаточно, вы должны проверить, что значение такое же поскольку это была версия программного обеспечения, которое сохранило файл. (Теперь добавьте атрибут версии в корневой объект!)

вам лучше сохранить набор примеров файлов данных для каждой поставляемой версии и иметь тесты, чтобы убедиться, что вы все еще можете их читать. Это сложнее, чем кажется на первый взгляд, так как значение полей объекта может меняться от версии к версии, поэтому одной возможности создать текущий объект из старого сериализованного файла недостаточно, вы должны проверить, что значение такое же поскольку это была версия программного обеспечения, которое сохранило файл. (Теперь добавьте атрибут версии в корневой объект!)

Да, если то, что нужно протестировать, должным образом протестировано с небольшим вмешательством.

Тот факт, что вы сериализуете и десериализуете в первую очередь, означает, что вы ' re, вероятно, обменивается данными с «внешним миром» - миром за пределами домена сериализации .NET. Следовательно, ваши тесты должны иметь аспект, выходящий за пределы этой области. Нехорошо тестировать Writer с помощью Reader, и наоборот.

Дело не только в том, закончите ли вы просто тестировать сериализацию / десериализацию .NET; вы должны протестировать свой интерфейс с внешним миром - что вы можете выводить XML в ожидаемом формате и что вы можете правильно использовать XML в ожидаемом формате.

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

Предположим, вы поручаете делать заметки и читать заметки одному и тому же человеку:

You - Bob, I want you to jot down the following: "small yellow duck."
Bob - OK, got it.
You - Now, read it back to me.
Bob - "small yellow duck"

Итак, что мы здесь протестировали? Боб действительно может писать? Боб вообще что-нибудь писал или запоминал слова? Боб действительно умеет читать? - его собственный почерк? А как насчет почерка другого человека? У нас нет ответов ни на один из этих вопросов.

Теперь давайте представим Алису картинку:

You - Bob, I want you to jot down the following: "small yellow duck."
Bob - OK, got it.
You - Alice, can you please check what Bob wrote?
Alice - OK, he's got it.
You - Alice, can you please jot down a few words?
Alice - Done.
You - Bob, can you please read them?
Bob - "red fox"
Alice - Yup, that sounds right.

Теперь мы точно знаем, что Боб может писать и читать правильно - пока поскольку мы можем полностью доверять Алисе. Статические данные XML (в идеале проверенные на соответствие схеме) должны быть достаточно надежными.

Предположим, вы поручаете делать заметки и читать записи одному и тому же парню:

You - Bob, I want you to jot down the following: "small yellow duck."
Bob - OK, got it.
You - Now, read it back to me.
Bob - "small yellow duck"

Итак, что мы здесь проверили? Боб действительно может писать? Боб вообще что-нибудь писал или запоминал слова? Боб действительно умеет читать? - его собственный почерк? А как насчет почерка другого человека? У нас нет ответов ни на один из этих вопросов.

Теперь давайте представим Алису картинку:

You - Bob, I want you to jot down the following: "small yellow duck."
Bob - OK, got it.
You - Alice, can you please check what Bob wrote?
Alice - OK, he's got it.
You - Alice, can you please jot down a few words?
Alice - Done.
You - Bob, can you please read them?
Bob - "red fox"
Alice - Yup, that sounds right.

Теперь мы точно знаем, что Боб может писать и читать правильно - пока поскольку мы можем полностью доверять Алисе. Статические данные XML (в идеале проверенные на соответствие схеме) должны быть достаточно надежными.

Предположим, вы поручаете делать заметки и читать записи одному и тому же парню:

You - Bob, I want you to jot down the following: "small yellow duck."
Bob - OK, got it.
You - Now, read it back to me.
Bob - "small yellow duck"

Итак, что мы здесь проверили? Боб действительно может писать? Боб вообще что-нибудь писал или запоминал слова? Боб действительно умеет читать? - его собственный почерк? А как насчет почерка другого человека? У нас нет ответов ни на один из этих вопросов.

Теперь давайте представим Алису картинку:

You - Bob, I want you to jot down the following: "small yellow duck."
Bob - OK, got it.
You - Alice, can you please check what Bob wrote?
Alice - OK, he's got it.
You - Alice, can you please jot down a few words?
Alice - Done.
You - Bob, can you please read them?
Bob - "red fox"
Alice - Yup, that sounds right.

Теперь мы знаем с уверенностью, что Боб может писать и читать правильно - пока поскольку мы можем полностью доверять Алисе. Статические данные XML (в идеале проверенные по схеме) должны быть достаточно надежными.

что мы здесь тестировали? Боб действительно может писать? Боб вообще что-нибудь писал или запоминал слова? Боб действительно умеет читать? - его собственный почерк? А как насчет почерка другого человека? У нас нет ответов ни на один из этих вопросов.

Теперь давайте представим Алису картинку:

You - Bob, I want you to jot down the following: "small yellow duck."
Bob - OK, got it.
You - Alice, can you please check what Bob wrote?
Alice - OK, he's got it.
You - Alice, can you please jot down a few words?
Alice - Done.
You - Bob, can you please read them?
Bob - "red fox"
Alice - Yup, that sounds right.

Теперь мы точно знаем, что Боб может писать и читать правильно - пока поскольку мы можем полностью доверять Алисе. Статические данные XML (в идеале проверенные на соответствие схеме) должны быть достаточно надежными.

что мы здесь тестировали? Боб действительно может писать? Боб вообще что-нибудь писал или запоминал слова? Боб действительно умеет читать? - его собственный почерк? А как насчет почерка другого человека? У нас нет ответов ни на один из этих вопросов.

Теперь давайте представим Алису картинку:

You - Bob, I want you to jot down the following: "small yellow duck."
Bob - OK, got it.
You - Alice, can you please check what Bob wrote?
Alice - OK, he's got it.
You - Alice, can you please jot down a few words?
Alice - Done.
You - Bob, can you please read them?
Bob - "red fox"
Alice - Yup, that sounds right.

Теперь мы знаем с уверенностью, что Боб может писать и читать правильно - пока поскольку мы можем полностью доверять Алисе. Статические данные XML (в идеале проверенные по схеме) должны быть достаточно надежными.