Николай Мишин

Может сдох выход или наушники?
у меня почти сдох выход, и уши не видятся
я поставил pavucontrol(регулятор громкости пульсы) и уже в проге вручную меняю устройство которое должно работать

Можно попытаться написать отдельный класс, в котором будет происходить создание вашего объекта
Общий смысл в том, чтобы использовать Primary, которому будет отдаваться предпочтение при создании бина
Что-то типа

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;

import static org.mockito.Mockito.*;

@Configuration
public class MockConfiguration {


	@Primary
	@Bean
	public ActivitiGetTimerValueDelegateService activitiGetTimerValueDelegateService() {
		ActivitiGetTimerValueDelegateService service = mock(ActivitiGetTimerValueDelegateService.class);
		when(service.getTimerValue(any(), any(), any())).thenReturn(42);

		return service;
	}

}

Присоединяйся к разработке the-tale.org

Все исходники открыты: https://github.com/Tiendil/the-tale

Берёшь задачу делаешь, делаешь пул-реквест, получаешь критику, пока всё правильно не будет сделано, и код попадает в рабочий проект.

В вики на гитхабе рассказано подробнее.

Пользуйся для этого к примеру gitter, вот скажем идет разработка открытого проекта на react

Нет никаких сферических "профи" и "не профи". Каждый разработчик пытается выявить и решить противоречия, пробует разные техники. С тестами (даже написанными через 2 недели после) вы будете чувствовать себя гораздо комфортнее психологически. Просто пишите тесты хоть тушкой, хоть чучелом. Но это тактический прием.

Более важно, полагаю, предусмотреть и поддержать максимальное количество сценариев(юзкейсов) использования продукта, причем наиболее простыми средствами. Главный показатель качества: попали в паттерн привычного поведения пользователя и сделали ему лучше. Количество багов нельзя рассматривать в отрыве от сути продукта.

Убрать редкие и сложные фичи, которые нужны 10% пользователей может дать для качества больше, чем все тесты.

TDD на практике встречается довольно редко, чаще код пишут сорт оф одновременно с тестами.

С багами мы боремся сейчас так:

* «первая линия» – юнит-тесты
* автоматические интеграционные тесты: эмулируют пользователя, елозят мышкой, жмут кнопки. Проверяют несколько сотен наиболее востребованных сценариев.

Это всё происходит в CI каждый коммит. Дерево всегда должно быть «зелёным»: если тесты не проходят, задачей с самым высоким приоритетом становится починка.

Затем (перед релизом) наступает:

* мануальный QA
* догфидинг: компания всё время использует собственный продукт. Таким образом, ручным тестированием занимаются вообще все, в той или иной степени.

Подход "Разработка через тестирование" действительно помогает сосредоточиться на выполнении конкретной задачи. Из плюсов:
- разработчик знает конкретные критерии "приемки" задачи
- выстраивается хорошая практика покрытия тестами

более подробно о подходе можно посмотреть в вики

Один коллега посоветовал мне сначала писать тесты, а потом уже под них писать код. Мы так еще не делали, хотим внедрить. Действительно ли это эффективно?

Да, так пишется меньше кода :)

Только в последовательность выглядит так
0. Пишем тест под новый функционал
1. Стартуем тесты = прогон тестов должен занимать до 2 сек
2. Видим новый проваленный тест
3. Фиксим его

Но в любом случае, сначала заводится тикет в багтрекере, потом вешается на себя, потом делается "гит пулл", а уже после того добавляется код

Различные среды дев/прод/тест должны готовится автоматом + должны быть в виде готовых образов для виртуалок или для докера.
Последовательность: пишется скрипт для сборки образа, отправляется в репозиторий, ночью или моментально машина, ответственная за образы, собирает его и разраб может ею пользоваться.
ИМО дев/прод/тест не должны различаться на данном етапе - все модификации окружения должен проводить софт, который ассоциирован с ЯП/средой, в которой ты занимаешься разработкой. Допустим ты работаеш с нодой и тебе нужны пакеты для оптимизации цсс - npm install а на продакшене такое не нужно и ты делаешь npm install --production

Но все ети заморочки не добавляют скорости разработки - они не дают разводить на проекте бардак и, теоретически, повышают качество кода

На странице Administrator Guide » Repositories подробно описан процесс настройки репозиториев в Редмайне, а так же указаны требования для Git
Репозиторий предназначенный для Редмайна должен быть bare типа, но не working tree - возможно у тебя именно эта проблема
git clone --bare {{repo_url}} {{local_path}}
Затем полный путь до {{local_path}} указать в Редмайне

Мы недавно сделали Redmine Agile plugin.
Есть доска задач и основные диаграммы Burndown, Cumulative flow, Velocity, Lead time. Скоро добавим swim lines, sprint planning и чтонибудь еще интересное :)

С гитхабом можно и по http(s) работать. Эти порты обычно открыты.
Пример:
git clone http://github.com/name/xxx.git
Но если на работе ходите через прокси, то ее тоже придется прописывать.