А вот интересно, тесты в оргмоде как-нибудь автоматически или хотя

бы регулярно гоняют?

не уверен, что там они ваще есть

Есть, но на сайте про это ничего не написано, так что вряд ли там хорошее покрытие

Я не понял вопрос, но он звучит интересно. Можно переформулировать понятнее?

Настроен ли у них CI в виде автоматического прогона тестов до и/или после влития изменений в master. Или может, на худой конец, ответственный за релизы их гоняет перед публикацией. Просто практика показывает, что если тесты есть, но регулярно не запускаются, то они все сломаны. А значит толку от них 0

А, это вопрос про тестирование пакета org-mode. Это не знаю. Я тесты в орг-документах гоняю.

Кажется, они тоже) А ты их прямо вручную из емакса всегда запускаешь, или можно это дело в какой-нибудь CI ещё запихать? Даже если только сам над кодом работаешь, всё равно хочется иметь "последний рубеж", чтобы репка сама ругалась, если ты забыл какие-то тесты прогнать и что-то сломанное в неё залил

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

Если можно make запустить, значит и в CI можно прогнать. Разбираться там особо нечего. Все эти тулы - это мелкая автоматизация по сути. Можно автоматом гонять тесты на PR и не разрешать их мержить, если не прошло, а можно гонять тесты и собирать билд по факту появления в мастере свежих коммитов или по расписанию. Если в последнем случае ещё и деплой подцепить, то будет CD. Всякие прекомит хуки - это ортогональная практика. Но можно то же самое делать не локально, а на PR перед мержем, например. А про свои тесты в оргмоде в любом случае расскажи тоже подробнее, плз

>PR Гоните его насмехайтесь над ним

Давай уж раскрой мысль та!

см. дискуссию про мейлинг листы

Где?

Я, в этом плане не настоящий сварщик. В рассылках только, бывало, тусил

define сварщик

Анекдот был

> А про свои тесты в оргмоде в любом случае расскажи тоже подробнее, плз 15:56 Идея такая: мне нравится когда тесты и их результаты присутствуют в очень непосредственном виде и легко доступны юзеру функции / библиотеки. Примеры использования функции / интерфейса это частный случай тестов: написано вычисляемое выражение, написан результат. Заодно если их оформлять так же как остальные тесты, гарантируется консистентность документации и кода, по крайней мере в том объеме, в котором примеры в документации обещают, как работает код. Поэтому вот как, грубо говоря, выглядит типичный раздел в моем орг-файле, где определяется функция (в данном случае — макрос `sow`): ``` ** Summary... ** Examples [...] *** TEST-PASSED Sow into different targets #+begin_src lisp :tangle no :load no :results value verbatim :wrap example lisp :package serere-tests (reap ((:squares :cubes)) (loop :for i :from 1 :to 10 :sum (1+ (- (sow (expt i 3) :cubes) (sow (expt i 2) :squares))))) #+end_src #+EXPECTED: #+begin_example lisp 2650 (1 4 9 16 25 36 49 64 81 100) (1 8 27 64 125 216 343 512 729 1000) #+end_example ``` Написано короткое название, что делает код в примере, написан код, написан ожидаемый результат. Если я сделаю `M-x run-nearest-test`, то в нормальной обстановке просто получу сообщение Test passed. В ненормальной будет что-то типа этого: ``` **** TEST-FAILED Sow into different targets #+begin_src lisp :tangle no :load no :results value verbatim :wrap example lisp :package serere-tests (reap ((:squares :cubes)) (loop :for i :from 1 :to 10 :sum (1+ (- (sow (expt i 3) :cubes) (sow (expt i 2) :squares))))) #+end_src #+RESULTS: #+begin_example lisp 2650 #+end_example #+EXPECTED: #+begin_example lisp 2650 (1 4 9 16 25 36 49 64 81 100) (1 8 27 64 125 216 343 512 729 1000) #+end_example ``` Соответственно, можно одной командой прогнать тесты во всем орг-буфере, и получится информативный дифф о том, что сломалось. Поскольку это Emacs, он даже будет интерактивный, так что буфер с диффом можно назвать `*failed tests in <whatever>*`, прыгать из него по сломанным местам и чинить. Ну или не чинить, а коммитить так — будет явное описание того, что сломано, прямо в коде. У этого подхода есть некоторые шероховатости, и я их еще чиню. Но в общем-то пользуюсь постоянно. Такой у меня получается TDD, так сказать.

Классно. А M-x run-nearest-test - это что-то своё или из орговой коробки? Щас комп не под рукой посмотреть

Не, тут все мое. Никакого #+EXPECTED нету тоже, и я никогда не видел чтоб кто-то использовал орговские todo-киворды для этой цели.

Есть, где глянуть? Не критично, не срочно, но с кодом всегда лучше

• https://gitlab.com/akater/org-development • https://gitlab.com/akater/org-development-elisp Но многое корявое еще, и я не рекламирую нигде, только если кто-то интересуется вот. И поскольку я пишу так примерно все что могу, в т.ч. сами эти пакеты, устанавливать их пока что тяжело. Я в процессе, но у меня, как это часто бывает, больше идей чем ресурсов их реализовывать, так что все медленно.

Спасибо! Посмотрю

я вот посмотрела на твое творчество и подумал о другом варианте. стандартный орг-бабель, но одна дополнительная функция -- запускает блок(и) и сравнивает результаты с тем, что в #+result

Ну а я так и делаю, не?