testomat.io управление авто тестамиДля джуниоров - может быть. Но мидлов / сеньоров, как правило, просят реализовать методы, не прибегая к использованию готовых имплементаций. Фактически, нужно написать свою реализацию. Например, сортировку или сравнение кастомных объектов.
тогда пойдет.
кстати, о сортировке. часто приходится писать или использовать сортировку?
проверять, что список отсортирован - да, но для этого сравнения достаточно.
а именно сортировку?
Depends on…
Если, к примеру, у вас сайт умеет сортировать сложные объекты по нескольким полям (jobs, clients data и т.п.), то наверняка вы предусмотрите какие-либо тестовые сущности - классы, объекты которых будут хранить все, считанные из UI, поля. Так вот в таком случае без реализации собственной сортировки вы не сможете проверить коррекность результирующей выборки. Конечно можно в лоб передавать expected захардоденный список, но что если на ручные просчеты по его формированию уходит достаточно много времени? Или имеется очень большая выборка, постоянно меняющиеся данные и т.п.? В общем, нюансов достаточно много. Но реализация собственного алгоритма сортировки сэкономит вам кучу времени в будущем.
вот не уверена, если честно. если вы реализуете свою сложную сортировку - не пытаетесь ли повторить работу дева? и повторять их ошибки, если что.
для проверки того, что список отсортирован, достаточно пройтись по нему и проверить, что каждый элемент отвечает условию (больше или меньше предыдущего). достаточно сравнения, не нужны перестановки.
2 лайка
А автоматизаторы - разве не девы? Повторять ошибки - значит содрать реализацию девов, или не разобраться в требованиях к алгоритму.
Как вы собираетесь проходиться по огромному списку и проверять неявные условия? К примеру, у вас есть jobs board, в котором реализован сложный алгоритм поиска по локейшену со встроенной сортировкой. Т.е., вы изначально не сможете проверить корректность расстояния между двумя пунктами по одному лишь имени локейшена.
А что если на сортировку накладываются дополнительные фильтры: для зарегистрированного юзера, имеющего CV, расстояние будет высчитываться от его места расположения; для юзера без CV / незарегистрированного юзера - от исходной точки поиска? У вас нет географических координат, но есть отсортированный по удаленности список, причем, не ясно, какая точка является начальной. В такой ситуации вам, как минимум, придется найти географические координаты 2х локейшенов, посчитать расстояние по определенным формулам, учесть наявность CV / статус юзера и т.п. И это анализ всего лишь одного элемента списка. Далее вам нужно пройтись еще по “нескольким” элементам для сравнения.
А что, если на данную сортировку наложены еще какие-либо фильтры? Или сортировка проводится по нескольким столбцам. Представьте на минуточку, сколько времени вы убьете на то, чтобы перебрать вручную хотя бы базовые наборы входных условий. Ну а повторив алгоритм, вы мало того, что сможете сэкономить себе время на ручном тетсировании, а еще и найдете возможные алгоритмические ошибки дева.
а как руками это проверят?
Полезут в платную базу геолокаций, найдут географические координаты обоих точек, посчитают расстояние по спец. формулам. Если юзер с CV, зайдут в профиль, посмотрят, есть ли там локейшен, определят его гео координаты по БД, наложат дополнительные условия и т.п. Ну т.е. руками это делать - геморрой еще тот.
Плюс ко всему, никто не отменял человеческий фактор, когда “не туда посмотрел / отвлекли / 5 часов подряд занимаешься одним и тем же / математика хромает” и т.п. В общем, трудоемкие вычислительные операции / неявные условия / множество фильтров - это как раз таки повод задуматься над реализацией алгоритма, хотя бы с целью экономии времени и сокращения рутинной работы.
честно? вот не стала бы писать свою сортировку - шансов ошибиться не меньше, чем у разработчиков. и времени на разработку уйдет много. и юнит-тестами эту реализацию еще покрывай.
тестировала бы по ожидаемым результатам.
Типа для юзера№1 при таких-то условиях должны быть такие результаты. для юзера№2 - другие.
2 лайка
У нас с девом ушло дня 3 с учетом синхронизации результатов. Это много или мало? А сколько вы потратите времени на написание и саппорт таких кейсов в случае изменения:
- локейшенов;
- алгоритма поиска / сортировки;
- CV пользователя;
- наложенных фильтров?
В случае с автоматизацией - минимум, и только в случае изменения алгоритма. В случае с ручным тестированием - каждое изменение повлечет за собой дополнительный перерасчет. Плюс ко всему, если вдруг сломается алгоритм, вы можете и не узнать этого наверняка, если результаты будут на поверхности одинаковые, но стоит вам изменить критерий поиска (добавить фильтр, изменить одну точку и т.п.), - все сломается. Т.е. проводя регрессию, вы каждый раз будете надеяться на то, что ваши старые расчеты при строго определенных обстоятельствах, дают правильный результат. А ведь на более низком уровне вы бы сразу смогли выявить проблему.
В общем, вопрос достаточно тонкий. И далеко не всегда оно того стоит. Я лишь привел пример, когда это действительно окупилось в плане временных затрат. Но это совсем не значит, что ваш подход - не применим. Во многих ситуациях он будет даже более действенным. Но вы ведь сами попросили привести пример. 
за пример спасибо.
ну, вроде тестирование должно это учитывать, не? то есть, для такого сложной фильтрации явно надо будет набор тестов, по которым можно определить, какая часть сломалась, в случае чего?
Пример действительно очень интересный
И сколько времени в итоге уйдет на анализ / создание / саппорт такого сьюта? Да и где гарантии, что этого набора будет достаточно? Разница в том, что в случае с описанным подходом каждый новый тест не потребует никаких доп. вычислений, т.к. алгоритмы уже реализованы. А так все придется считать ручками, еще и периодически освежать наши тесты.
Понятно, что людей из других городов тяжело собеседовать, но если людей всегда не хватает, то приходиться искать и по телефону в том числе.
Девы и к ним тоже должны относиться, как разработчикам, тогда и код будет соответствующий. Вот я как бы автоматизатор, но пишу библиотеки на python сейчас и к ним пишу юнит тесты. Вроде бы юнит тесты и не нужны, но для того, чтобы библиотеки не ломались по каждому чиху, надо правильно программировать.
Друзья, напрашивается вопрос - как часто вы закрываете позиции ?
3 лайка
Смежная тема
Давече
1. Python
Написать декоратор, который перед вызовом декорируемой функции выведет строку.
Декорировать любую функцию с любыми параметрами.
На листочке.
2. JavaScript
Дано
function Music(url) {
this.url = url
}
Music.prototype.play = function() {
//...
}
var music = [new Music("111"), new Music("222"), new Music("333")]
написать последовательный проигрышь (вызов play), с интервалом 10 секунд.
Код пишется онлайн, соответственно должен быть рабочим.
3. “Люди в комнате - остаться должен только один”
Реализовать задачку
Дано n людей в комнате. Есть судья (арбитр).
Судья начиная с первого человека чередует “остаешься” и “иди вон”.
Пройдя круг повторяет с оставшимися в том же порядке, до тех пор пока в комнате не останется один человек.
Каким по порядку был этот человек при первом цикле?
На примере объясняется так:
n = 4
+ + + + (сначала все)
+ x + x (арбитр 2му и 4му сказал идти вон)
+ x x x
=> остался 1й
n = 3
+ + +
+ x + (только 2й ушел, 3му остаться)
x x + (т.к. перед этим 3й остался, то сейчас 1му "вон")
=> остался 3й
Код пишется онлайн, соответственно должен быть рабочим.
3 лайка
Насчет фибоначи на javascript-e, как было сказано выше. Обычная реализация рекурсией покажет что у вас есть знания что такое рекурсия, это да, но она очень неоптимальная, если знать как и что работает в жс-е. Основные возможности ускорения расчетов с примерами можно посмотреть вот тут http://jsperf.com/fibonacci-y-combinator/5 . Там все понятно и просто, но если есть жедание, могу расписать каждый пример отдельно, почему он выполняется быстрее и тд и тп.
Я ось думаю - всі на проектах використовують фібоначі і тому подібну дурню? 0_о снобізмом попахує… Може ви Кнута на пам"ять всього знаєте?
2 лайка
Дело не в последующей пригодности на проекте, а в том, что на мат. задачках легко проверить понимание основ языка и умение выбрать правильный подход в реализации. К примеру, даже дав вам определение чисел Фибоначи, можно оценить вашу способность придумать алгоритм решения. А потом еще попросить объяснить, что валидней использовать: циклы или рекурсию, к примеру. Как все это дело может отразиться на времени выполнения и т.п. Т.е. задача не в том, чтобы проверить знание каких-то формул, а в том, чтобы оценить ваше мышление.
3 лайка
Взято из темы Тестирование Rest API c помощью python средств
Python:
Using API documentation below verify that all endpoints (methods) on server**
work as expected (accessible and return correct response codes for all cases).
Output should be:
- Code that verifies that data is added to server.
- Code that verifies correctness of returned response codes.
Small tips.
● POST request accepts name and position in body;
● Body is expected to be in JSON format;
● All requests with body should contain correct “Content-Type” header;
● Not all methods might work as expected;
● In this section you do not need to parse response, only to verify that
“some” data was uploaded to server.
**Please note that your are not the only person using this server, thus you might notice that
there will be some data which you did not create, as well as your data might be occasionally
deleted by other users.
NICE TO HAVE:
Python:
For the Python task mentioned above:
- Verify that all methods working as expected.
- All data is correctly added to server.
Small tips:
● Try to create positive and negative verifications;
● In this section you do need to parse response received from server.
This document contains confidential and proprietary information and may not be reproduced or distributed in
any manner without the express consent of Cogniance Inc. ©2014 Cogniance Inc, a Delaware, United States
corporation. All rights reserved.
Datamining:
Use existing access log (any language) to receive next information:
- Count # of successful requests per hour.
- Results should be stored in file.
Small tips:
● Log contains data only for 1 day;
● Successful request should have response code 200;
● Easiest way to achieve that - *unix command line.
OUT OF THE BOX:
Python & Redis:
For “OUT OF THE BOX” level make several enhancements to Python tasks from
the “OK LEVEL” and “NICE TO HAVE”. Create a DB using Redis in which candidate
names and positions will be stored. In order to accomplish this task:
- Redis should be installed on local machine.
- All requests to server that require passing names and positions within your
test should take that data from Redis.- All comparisons that touch verification of the names and positions you have
in test should be done using data from Redis.
Datamining:
Use existing access log (any language) to receive next information:
- Count % of successful requests per hour.
- Results should be stored in file.
Small tips:
● Log contains data only per 1 day;
● Successful request should have response code 200;
● Easiest way to achieve that - *unix command line.
API DOCUMENTATION:
Server allowed methods:
GET, http://qainterview.cogniance.com/candidates, gives a list of all candidates.
Returns 200.
GET, http://qainterview.cogniance.com/candidates/<cand_id>, shows a
candidate with id=<cand_id>. Returns 200
POST, http://qainterview.cogniance.com/candidates, adds a new candidate.
Returns 201. Case when header Content-Type: application/json or name is
absent, 400 is returned.
DELETE, http://qainterview.cogniance.com/candidates/<cand_id>, deletes a
candidate with id=<cand_id>. Returns 200