Я БЛЯТЬ БУДУ ЕГО ПЕРЕПИСЫВАТЬ НА РАСТЕ

тоесть он блять в принципе в пизду нужен

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

ты можешь его переписать, а тесты оставить

а структуру аутпута я в комментах прописал и файлике оутпута с выводом

тесты сразу на расте просто напиши

Или хотя бы проверить результат ака код возврата

ты можешь его переписать, а тесты оставить

хуй там

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

sic! у меня такого нету

ну может тестов 10 под это правило у меня подойдут

не более

10 — больше нуля)

тесты сразу на расте просто напиши

блэт, парсер на питоне, отдает жпс, мне типо проверять юниттестами аутпут относительно узлов serde?

А для остального — e2e как тут уже сказали

С учетом что потом на расте будет переписано все, под свои узлы и тд

тесты сразу на расте просто напиши

Да это дичь. Тестить парсер на питоне надо тестами на питоне)

А для остального — e2e как тут уже сказали

для e2e дохуя в целом можно сделать

не большой любитель ложки? вилки наше все?

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

вот только я хуй знает как e2e относительно gtk делать

блэт, парсер на питоне, отдает жпс, мне типо проверять юниттестами аутпут относительно узлов serde?

Это интеграционный тест и это дроч ненужный в данном случае

Это интеграционный тест и это дроч ненужный в данном случае

а я о чем

если парсер написан не тобой, то тестировать бессмысленно, да

к тому же, я сейчас сдам очередной деллайн, и потом надо все яйца в кулак собрать и написать парсер

на одном дыхании

без спидов(

ибо я просадил толер в ноль

а абсолютный ноль

Итератор же иммьютабл. Ты можешь менять ключи, но удалить элемент в процессе итерирования — нет. Тут тебе не жава

https://crates.io/crates/intrusive-collections - это же Rust, здесь можно написать всё, что надо, если нет 😊 Правда это называется курсор, а не итератор 😊

ноль на котором я скорее умру от инфаркта чем получу концентрацию и внимание к деталям

https://crates.io/crates/intrusive-collections - это же Rust, здесь можно написать всё, что надо, если нет 😊 Правда это называется курсор, а не итератор 😊

С подключением) // тот самый mersinvald, который хэйтил ньюкамеров и выселял их в гетто

https://crates.io/crates/intrusive-collections - это же Rust, здесь можно написать всё, что надо, если нет 😊 Правда это называется курсор, а не итератор 😊

ну да. в принципе и в lmdb-rs это курсором называется

ну в общем то так себе интерфейс короче. мне прям дали двустволку

и я сразу выстрелил себе в ноги

и в голову после

С подключением) // тот самый mersinvald, который хэйтил ньюкамеров и выселял их в гетто

)))

https://crates.io/crates/intrusive-collections - это же Rust, здесь можно написать всё, что надо, если нет 😊 Правда это называется курсор, а не итератор 😊

Найс, но эта штука не инвалидируется при изменении, в отличие от.

Там скорее по другому работает. Курсор начинает указывать куда-то ещё при удалении (или никуда, если уже некуда). То есть в целом подход сильно другой, да.

"начинает указывать на" => "устанавливается на" 😊

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

про тесты уже все?

про тесты уже все?

видимо да

мы выяснили что тесты хуйня

таааак

triggered

неправильно выяснили

гуй конечно сложно юнит-тестировать

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

но

вот расскажи свой цикл разработки

ну кто-нибудь

вот расскажи свой цикл разработки

> Придумал идею > Сделал первую реализацию > накатил поверх нее еще приблуд > Видишь что говно, рефакторишь/переписываешь > GOTO start

к тому же для gtk вообще нет никаких паттернов разработки

так что я придумываю их поверх вьюхи на ходу

остальные растодрочеры вообще не делают архитектуру гуев

вот расскажи свой цикл разработки

Пишешь лесенку, не хватает чегото- дописываешь пару ступенек

сириусли если глянуть любое приложение, там просто один main в который запихали лапшой все и сразу

как ты узнаешь что нехватает чего-то?

как ты узнаешь что нехватает чего-то?

аллах во сне дает мне откровения

Пусть тогда Аллах и тестирует

Пусть тогда Аллах и тестирует

sic]

Ну а если серьезно, то многое без тестов загнется

Например байтодрочерство

аллах во сне дает мне откровения

интесный способ разработки

Ну а если серьезно, то многое без тестов загнется

ну это да

я просто сравниваю с лично своим проектом

и говорю - что тесты не панацея даже близко

особенно на первых этапах

когда есть некий стэйбл - то без базару интеграционки напишу и дело с концом

Панацея, еслиб был патерн для простого создания тестов для гуи

А так, тебе просто дороже было бы освоение такой херни, чем накидывание тонн говнокода

Ну вот с архитектурой и парсерами. Пишешь текстовый парсер. К нему "рендер" в обратном направлении. Получается такая себе нормализация строки. Тестируешь, что на входе в парсер и выходе из рендера всё как надо, при том, что это не одна и та же строка. Меняешь архитектуру как хочешь и сколько угодно раз, возможно по пути немного меняется вызов парсера и рендерера, но не более того. Но в процессе тесты со строками остаются неизменными и показывают, где что отвалилось, если вдруг (а оно часто бывает, когда полез архитектуру вверх дном воротить). ??? ПРОФИТ!

Во-во, для парсера кстати очень применимо

Но с ГУИ - без специально обученного человека™ обычно туго...

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

а за тебя это может сделать комп

Ибо явно ж после переписывания всего добра на раст, что-то явно сломается

И будет шрамко ныть, что ещё день проебал на дрочку с сьехавшим дизайном

Но с ГУИ - без специально обученного человека™ обычно туго...

Можно функционал тестить вполне, "нажал кнопку - что-то произошло". А человек нужен просто для юзабилити и комплексного тестирования. Но для такого человека ещё нужно требования написать, как всё должно работать

Ну, а чем программа написанная на русском языке будет отличаться от программы написанной на ЯП, кроме ненадёжности платформы, на которой она запускается? 😊

Короче шрамко