Автоматизированное Тестирование: способы помочь и обучить разработчиков? [закрытый]

A few things I'd do:

1. Get them to run coverage and spot any missed areas of code and highlight how although they think they've got all the cases covered, they might not have. I've done this with a few people and they always seem quite surprised at areas they've missed when they thought they'd written watertight tests
2. Start a "recipe" page on your local Wiki. Every time someone comes up with a testing scenario that they can't figure out, or need your help with, stick it on the Wiki and make it easy to find. Get other people to contribute as well
3. It sounds like you're already doing this anyway, but ensure when anyone has a testing related question, make yourself available even if it's to the detriment of your normal workload. If you're passionate about it, it should inspire those who are interested to do the right thing too.

When I'm introducing someone to testing (or a new testing technique), I'll often spend alot of my time randomly wandering over to their workstation just to see how they're getting on and nudge them in the right direction. This can be fitted in quite nicely when going for tea/smoke breaks or when you're doing a build. I've had quite good feedback about this but YMMV.

В зависимости от размера команды, мне интересно, имеет ли смысл после первоначального обзора кода привлекать кого-то еще, чтобы он мог видеть то, что меняет вас Я бы предложил и действовал как способ показать, что это не только ваше мнение по этому поводу. Это может работать как способ подчеркнуть, где может возникнуть некоторая напряженность с точки зрения того, какие изменения вы хотели бы видеть, на что разработчик может ответить: «О, это займет недели и, вероятно, того не стоит ...» или что-то подобное, если то, что вы хотели бы изменить, не так просто.

Аналогичным образом, как большая часть команды смотрит на тестирование? Есть ли лидеры или высокоуважаемые люди, которые положительно относятся к этому и способствуют формированию к нему положительного отношения? Есть ли общая документация о правилах тестирования, которая может помочь новичкам в команде быстро освоиться? Это всего лишь несколько других областей, которые я бы исследовал, поскольку иногда тесты могут быть отличным делом, а иногда - болью. Во многом как стакан, который наполовину пуст или наполовину полон, в зависимости от того, как вы хотите его видеть.

Не то чтобы я занимал такое же положение, но как человек, который какое-то время был разработчиком, это просто то, что я хотел бы видеть, чтобы помочь сделать тестирование полезным, как сказала бы Марта Стюарт.

Я буду обследовать, потому что иногда тесты могут быть полезными, а иногда - болью. Во многом как стакан, который наполовину пуст или наполовину полон, в зависимости от того, как вы хотите его видеть.

Не то чтобы я занимал такое же положение, но как человек, который какое-то время был разработчиком, это просто то, что я хотел бы видеть, чтобы помочь сделать тестирование полезным, как сказала бы Марта Стюарт.

Я буду обследовать, потому что иногда тесты могут быть полезными, а иногда - болью. Во многом как стакан, который наполовину пуст или наполовину полон, в зависимости от того, как вы хотите его видеть.

Не то чтобы я занимал такое же положение, но как человек, который какое-то время был разработчиком, это просто то, что я хотел бы видеть, чтобы помочь сделать тестирование полезным, как сказала бы Марта Стюарт.

Один из способов мягко облегчить команду при запуске тестов - начать практику написания тестов, когда ошибки исправляются. Поэтому, когда возникает ошибка, первое, что нужно сделать, - это написать тест, который не удастся из-за ошибки, исправить ошибку, а затем пройти тест.

Этот подход также может быть реализован, когда код изменяется изнутри (без изменений общедоступного API) - напишите тесты для покрытия изменяемой области, чтобы гарантировать, что она не будет нарушена изменениями кода. Написание тестов таким способом требует гораздо меньше усилий и наглядно демонстрирует преимущества, когда разработчик обнаруживает свою первую ошибку регрессии.