Парни, шутки-шутками, но определить, что число четное от 1 до 12 с поправкой на месяц…ну ведь это с++, а не c++script…
Не хочу критиковать, но и массив, с закладкой что месяц не индекс, плюс отдельная подработка внутри функции…неужели такое красивое решение?
Может и так, но это можно сказать про любой код. Определение дней в месяце легко вычисляется и логику можно сосредоточить в одном месте, а не глобальный массив с 13 элементами для 12 месяцев только невисокосного года, который еще 'доучитывается' в теле функции.
Да, и тут всё индивидуально. Я исхожу из своей практики, например, банальщина, коллега меня спрашивает: -Как дела? (how are you?). На русском, в зависимости от ситуации, мне нередко приходят фразы типа: «ну не так что бы уж очень и не то чтобы уж совсем», либо «как говорил мальчиш-кибальчиш, всё хорошо, да что-то не хорошо». На английском, я «спотыкаюсь» и просто отвечаю: same old, same old либо просто «no bad», что не совсем верно отражает исходную мысль. То есть для английского, мне приходилось либо упрощать речь, либо искать аналоги выражениям. То есть в итоге, я тратил больше времени, чем, например, некоторые знакомые, которые просто не парятся, и выстреливают слова формируя максимально простые фразы, потому что они почти также и думают (не хочу никого обидеть, и без претензий на грамотея, но уровень владения родным языком у людей разный).
Конечно, всё больше овладевая языком, такие переводы с русского уже не делаются, и неродная речь становится действительно богаче, но, на это уходит больше времени. Другими словами, чтобы свободно начать говорить на иностранном языке, кроме массы других факторов, мне кажется немаловажным и то, как именно мы думаем и говорим на своем родном языке.
Плюс, на мой взгляд, еще имеет значение насколько хорошо вы владеете своим родным языком. Если ваша речь богата, фразы разнообразны, вы публикуетесь, способны быстро, свободно и красиво излагать мысли на своем языке, то научиться говорить на иностранном будет сложнее, при том же запасе в 3000 слов, чем у индивидуума с речью попроще.
Может я неверно понял задачку, и признаюсь, не понял решение. Вот мой вариант: в пустое ведро на 7 литров налить из полного 5. Отметить пальцем уровень, и долить из реки до полноты в 7 литров. Вылить из ведра на 5 литров воду. Из ведра на 7 отлить до отметки в ведро на 5, это будет 2 литра. Затем опять полностью заполнить из реки ведро на 7 и вылить до отметки в ведро на 5. После этого в ведре на 5 будет 4 литра воды.
Да, я примерно прикидывал, это не сложно. Но я думаю, что делать полное покрытие типовых, скорее всего не стоит, ведь это за нас (по идее) уже сделали разработчики. Вопрос тут не просто в используемом инструменте, а в принципе, мы не разработчики типовых, нам будет крайне трудозатратно определять какие из падающих тестов нужно обновлять с выходом релизов (ведь тесты нужно будет поддерживать в дальнейшем).
Имеет смысл покрывать только то, что вы изменяете в типовой, также, создание библиотечных методов, для создания объектов – всё это делается очень просто. Нужно просто «набить руку». На каждый библиотечный тест уходит до ~15 минут. В общей сложности, таких тестов будет штук 15-20…и при этом, их не нужно делать для каждой конфигурации отдельно, библиотечный тест создания товара, покупателя и многих других будет практически одинаковый для УТ11, ERP2 и других
подскажите, что стоило бы спрятать? программный код многих сценариев содержит комментарии, которые являются частью изложения, а программный код доработок УТ11 неотъемлемая часть развития идеи кодирования вместе с тестами, т.е. пока не напишем код, дальше работать по статье не получится.
Спасибо! К сожалению, обычное приложение поддерживает лишь частично автоматизированное тестирование на основе взаимодействия клиента и менеджера тестирования, поэтому я боюсь, что реализация всего функционала будет сложной.
в России довольно много разговоров и пропаганды направлено на то что все вокруг враги
Русская пропаганда просто ребенок, по сравнению с западной. Продайте американцу русскую программу, уверяю вас, это будет сложно и как раз по причине прошитой зомбированности, русские пока такой, простите, паранойей, не страдают. Или сделайте поиск в гугле на русском с канадского айпишника — результаты вначале идут с украинских сайтов, хотя я прекрасно понимаю, что релевантность значительно выше из домена ru, что доказывает поиск из менее популярных западных поисковиков. Я ничего не имею против, пусть показывают новости и результаты, которые они контролируют, имеют полное право, но не нужно рассказывать всем про открытость, свободу и беспристрастность.
Нормальные люди с интеллектом и амбициями уезжают в Купертино,
Неплохо живут в своей стране. А про патриотизм расскажите американцам. Я вот живу в Канаде, внедряются тихонько 1с (не русским), сопоставимых российской программе конкурентных технологий в домене автоматизации здесь нет, и это не мое мнение, а со стороны.
Это очень спорный вывод. Сам работаю в команде, частая коммуникация признак того, что что-то идет не так, или кто-то не выполнил качественно свою работу. На своей практике — безуспешность проекта часто связана с размазыванием полезной информации по чатам и отсутствию фокуса у разработчиков.
А привычка 1С-ника получить серт и нести его работодателям… бросайте её ))
просто в качестве ремарки (я понимаю, что имидж — всё) но:
— сдать на спеца или эксперта значительно сложней и полезней, как для работника, так и работодателя, чем прозябание на форумах.
Я признаться, хотел вам задать такой же вопрос :-) Мы в своём почтовом клиенте используем ckeditor, было одно важное для нас требование — удобоваримая работа в старых версиях IE7+, которое ckeditor выполнял (на момент анализа вопроса) лучше всех.
Я в карьерно-профессиональном тупике. Мои текущие умения, знания и способности не дадут мне того, что я хочу. У меня уже близок потолок в части зарплаты и чтобы прыгнуть дальше — нужные качественные изменений
Вы не прыгните дальше, вы прыгните в сторону. Но чтобы переосмыслить, некоторым людям, действительно нужна встряска. Попробуйте, может повезет, но и вероятность сидеть какой-нибудь грид на данные натягивать, или еще какая рутина, очень велика.
понятно, а есть реальный опыт (положительный/отрицательный) в использовании такой документации конечными пользователями продукта? Или пока это больше для внутренних нужд.
Спасибо за развёрнутую статью!
Очень интересен ваш опыт, появилось несколько практических вопросов:
1. Подскажите пожалуйста, как написание сценариев пользователями синхронизируется с тестовыми данными? Возможно, ответ есть в статье, но я не смог понять, что в вашем случае является тестовыми данными, это данные, которые могут быть использованы в процессе работы теста, или это эталонные данные, с которыми тест потом сверяется.
2. У каждого пользователя свои тестовые данные?
3. Задействуются ли программисты в вашей схеме BDD?
Кроме этих трех пунктов, если это не является коммерческой тайной (что было бы справедливо), было бы очень интересно увидеть сценарий происходящего, на некотором практическом примере. Например: есть «постановка задачи», под неё пишется сценарный тест, далее он переходит к функциональщикам, те его шлифуют…и так далее до конца (последовательность здесь вымышленная).
Понимаете, очень часто, статьи про BDD описывают инструментарий и методику вокруг инструментария, но я нигде до конца не находил методику интеграции BDD в процесс разработки. Другими словами, хотелось бы увидеть, как решаются вопросы зачистки базы, что происходит при многократных итерациях запуска тестов, как проверяется бизнес-логика, с чего начинается написание сценария (например, если есть сценарий «Расхода» пишется ли вначале сценарий «Прихода» без которого тест «Расхода» не выполнится). Другими словами всё то, что без правильной методики при отсутствии сверх финансирования, нередко вынуждает отказываться от этой затеи.
Не хочу критиковать, но и массив, с закладкой что месяц не индекс, плюс отдельная подработка внутри функции…неужели такое красивое решение?
P.S. Мне кажется решение через if было бы не самым плохим:
Конечно, всё больше овладевая языком, такие переводы с русского уже не делаются, и неродная речь становится действительно богаче, но, на это уходит больше времени. Другими словами, чтобы свободно начать говорить на иностранном языке, кроме массы других факторов, мне кажется немаловажным и то, как именно мы думаем и говорим на своем родном языке.
Имеет смысл покрывать только то, что вы изменяете в типовой, также, создание библиотечных методов, для создания объектов – всё это делается очень просто. Нужно просто «набить руку». На каждый библиотечный тест уходит до ~15 минут. В общей сложности, таких тестов будет штук 15-20…и при этом, их не нужно делать для каждой конфигурации отдельно, библиотечный тест создания товара, покупателя и многих других будет практически одинаковый для УТ11, ERP2 и других
Русская пропаганда просто ребенок, по сравнению с западной. Продайте американцу русскую программу, уверяю вас, это будет сложно и как раз по причине прошитой зомбированности, русские пока такой, простите, паранойей, не страдают. Или сделайте поиск в гугле на русском с канадского айпишника — результаты вначале идут с украинских сайтов, хотя я прекрасно понимаю, что релевантность значительно выше из домена ru, что доказывает поиск из менее популярных западных поисковиков. Я ничего не имею против, пусть показывают новости и результаты, которые они контролируют, имеют полное право, но не нужно рассказывать всем про открытость, свободу и беспристрастность.
Неплохо живут в своей стране. А про патриотизм расскажите американцам. Я вот живу в Канаде, внедряются тихонько 1с (не русским), сопоставимых российской программе конкурентных технологий в домене автоматизации здесь нет, и это не мое мнение, а со стороны.
просто в качестве ремарки (я понимаю, что имидж — всё) но:
— сдать на спеца или эксперта значительно сложней и полезней, как для работника, так и работодателя, чем прозябание на форумах.
А ckeditor не рассматривали?
Вы не прыгните дальше, вы прыгните в сторону. Но чтобы переосмыслить, некоторым людям, действительно нужна встряска. Попробуйте, может повезет, но и вероятность сидеть какой-нибудь грид на данные натягивать, или еще какая рутина, очень велика.
Подскажите пожалуйста, это пользовательская документация или набор given when then?
Очень интересен ваш опыт, появилось несколько практических вопросов:
1. Подскажите пожалуйста, как написание сценариев пользователями синхронизируется с тестовыми данными? Возможно, ответ есть в статье, но я не смог понять, что в вашем случае является тестовыми данными, это данные, которые могут быть использованы в процессе работы теста, или это эталонные данные, с которыми тест потом сверяется.
2. У каждого пользователя свои тестовые данные?
3. Задействуются ли программисты в вашей схеме BDD?
Кроме этих трех пунктов, если это не является коммерческой тайной (что было бы справедливо), было бы очень интересно увидеть сценарий происходящего, на некотором практическом примере. Например: есть «постановка задачи», под неё пишется сценарный тест, далее он переходит к функциональщикам, те его шлифуют…и так далее до конца (последовательность здесь вымышленная).
Понимаете, очень часто, статьи про BDD описывают инструментарий и методику вокруг инструментария, но я нигде до конца не находил методику интеграции BDD в процесс разработки. Другими словами, хотелось бы увидеть, как решаются вопросы зачистки базы, что происходит при многократных итерациях запуска тестов, как проверяется бизнес-логика, с чего начинается написание сценария (например, если есть сценарий «Расхода» пишется ли вначале сценарий «Прихода» без которого тест «Расхода» не выполнится). Другими словами всё то, что без правильной методики при отсутствии сверх финансирования, нередко вынуждает отказываться от этой затеи.
Спасибо!