to post messages and comments.

GTX 970 vs GTX 650Ti на моем железе дал прирост в 908 3д-марковских попугаев. По осюсениям и по графике 970 примерно в 2-раза мощнее 650 )

DOOM реально полетел в космос, чоужтам. Неделю можно смело вычеркивать из жызни, /me шоке & ахуе от того DOOMа ) IDDQD & IDKFA!

Дополнительно налетел на замену БП, ибо питание PCI-E 8-и пиновое на карте, а на старом БП 380 — онли 6 пин. Взял Zalman ZM600-LX, извращаться с переходниками не стал, ибо системник забит под завязку всяческим гуаном и есть подозрение, что 380 ему маловасто даже без видео )

3dmark.com
3dmark.com

Нвидио отакое:

dns-shop.ru
overclockers.ru

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

Господа, подскажите как лучше сделать.
Задача: тестирование веб приложения на yesod.
Как я это себе вижу — идёт последовательно несколько тестов:
1. Добавление пользователя
2. Добавление этому пользователю некоего хранилища с секретом для подписывания (здесь мы где-то запоминаем id хранилища и секрет)
3. Добавление файлов в это хранилище.

Т.е. мне надо как-то шарить состояние между тестами. А hspec такого не умеет :( github.com И походу yesod.test основанный на нём не умеет тоже.
Можно, конечно, погдотовить некое тестовое окружение, т.е. добавить в базу нужные значения и пользоваться захардкожеными значениями.
Возможно, есть какие-то готовые рекомндации или всё самому?

а вот такой интересный вопрос, есть функция marker :: PutM Marker работающая только внутри монады,
есть операции над ней — toPtr :: Marker -> PutM (Ptr a), toAddr :: Marker -> PutM #Addr, distance :: Marker -> PutM Int
выдернуть эти значения из монады нельзя, но хочется протестить, всякие операции, типа
marker >> \x -> mapM (putWord8 0) d >> distance d == d
я вижу вариант только через unsafePerformIO и складывание результатов теста в MVar/IORef

как заставить test-framework печатать причину фейла quickcheck пропертей ? Если мой тесткейс возвращает QuickCheck.Property.Result то hspec печатает причину фейла, как такое сделать в test-framework ?

жуик, а как заставить hspec сказать в чем именно фейл теста ? Пилю persistent, дополнил тест, а он фейлится и не говорит где

CREATE TABLE "Author"("id" INTEGER PRIMARY KEY,"name" VARCHAR NOT NULL);
CREATE TABLE "Entry"("id" INTEGER PRIMARY KEY,"authorId" INTEGER NOT NULL REFERENCES "Author","title" VARCHAR NOT NULL);
CREATE TABLE "MaxLen"("id" INTEGER PRIMARY KEY,"text1" VARCHAR NOT NULL,"text2" VARCHAR NOT NULL,"bs1" BLOB NOT NULL,"bs2" BLOB NOT NULL,"str1" VARCHAR NOT NULL,"str2" VARCHAR NOT NULL);

rename specs
— handles lower casing
— extra blocks

data type specs
Test suite test: FAIL
Test suite logged to: dist/test/persistent-test-1.1.0-test.log
0 of 1 test suites (0 of 1 test cases) passed.

Это последнее что я вижу

увидел, что обновилась библиотека NUnit до версии 2.6.2 и объявлена поддержка "async" тестов.
обрадовался, что тесты теперь можно без проблем асинхронно гонять и, наверно, время прохождения можно уменьшить раза в 4.
но не тут то было. Nunit даже асинхронные тесты умудряется запускать по очереди ((

мда, всякие пиписькомерки — то еще говно. Только что прошел питонотест на одеске, с гуглом и копипастой в питоношелл. 4.25 из 5, т. е. 6 вопросов я проебал. Неплохо, чо.

А если писать тесты, то:
— не забудешь, какие варианты развития событий проверялись
— не надо будет проверять вручную каждый раз все варианты
— можно не бояться лажи в динамических языках
— можно думать меньше над возможными проблемами и больше выносить мыслей в код теста
— можно писать код уставшим и замученным, всё равно будет в разы меньше косяков
— дальше можно отдавать код хоть идиотам
— пока идёт полный прогон тестов, можно сходить за чаем!!1 PROFIT!!

Convert Project to Test Project

1: Open the Project file you wish to convert in notepad (or your favourite text editor)
2: Paste the following line in the <PropertyGroup> that contains <AssemblyName> etc:

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

3: Save the file
4: Open in Visual Studio.

Your project should now be a test project.


social.msdn.microsoft.com

avva.livejournal.com — апологеты TDD сами себе злобные буратины. Зачем демонстрировать метод, по сути, итеративного изучения предметной области на задачах, все аспекты которых легко удержать в голове.