Тэги

Silverlight (36) WPF (10) IIS (7) Visual Studio (7) SharePoint (6) .Net Framework (5) ODP.NET (5) ASP.NET (4) C# (4) common (4) Network Settings (3) JavaScript (2) MS Office (2) Resharper (2) WCF (2) WEB (2) XPath (2) XSLT (2) ADO.NET (1) APEX (1) CMD (1) CSS (1) EF (1) HTML (1) Hardware bugs (1) Java (1) MS SQL (1) Oracle (1) PDF (1) Version Control (1) XAML (1)

вторник, 20 марта 2012 г.

AutoFixture

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

Нет версии для Silverlight, но я легко ее доработал для работы в нем. Потребовались незначительные изменения.
Автор просто не использует Silverlight в своей работе.

Если полюбите, то не забывайте в Unit-тестах про тестирование пограничных значений!

Test Not First

From
http://www.simple-talk.com/dotnet/.net-framework/on-writing-unit-tests-for-c/

A practice that is made popular by Agile and Extreme Programming methodologies is ‘test-first development’. From Wikipedia: ‘The tests should be written before the functionality that is being tested’.

I don’t agree with that. Tests for a portion of code should be written at the same time as the code itself. I advocate this because not all edge cases can be faced up-front, even by domain experts or professional testers. Edge cases are generally discovered only when thoroughly implementing an algorithm. This is an iterative process where you write a few tests, then write the few corresponding lines of code and methods, and repeat until the features and classes are completely implemented and 100% covered by tests.

By talking with many who advocate test-first principles, I find that they are also talking of a process where code and test writing are iterated. We are certainly doing it all the same way in reality, and it is the term ‘test-first’ that seems misleading to me.With experience, one can anticipate how to design the code as testable. I often write the code with a testable design first, then the associated tests, and then repeat.