Комментарии 35
Когда ваша команда еще немного подрастет, вам придется слезть с JIRA и других инструментов от Atlassian по причине их низкой производительности.
Предложения?
Каково количество юзеров, с которых начинаются тормоза?
плюсую, тоже очень интересно что не так там с производительностью.
У нас больше сотни юзеров. Тормозов системы не наблюдаю.
Речь идет о тысячах пользователей.
Так на тысячи пользователей — это уже Atlassian Enterprise и его «Data Center» опции, с нужной масштабируемостью. Что, там тоже «проблемы с производительностью»?
На понимание: Jira у нас сейчас используется не только в подразделениях, занимающихся разработкой. Так что упомянутые тысячи пользователей в наличии и, как верно заметил коллега, «все шевелится».
Хотя, должен заметить, такое количество пользователей заставляет очень осторожно подходить к выбору плагинов. Неоднократно сталкивались с существенной деградацией производительности после установки некоторых из них.
Хотя, должен заметить, такое количество пользователей заставляет очень осторожно подходить к выбору плагинов. Неоднократно сталкивались с существенной деградацией производительности после установки некоторых из них.
ну пока шевелится вроде
Устанавливаем JIRA Server Edition сейчас. Было бы здорово услышать что нетак с системой.
«Команда немного подрастет» и «Речь идет о тысячах пользователей» — Ваши два комментария как-то не вяжутся между собой.
А зачем вы используете Sinon, если у вас проект на Angular и там есть встроенный FakeServer, называемый $httpBackend?
У нас есть проекты, которые не на AngularJS, там мы используем Sinon. Мне не хотелось тащить Angular в качестве примера, поэтому решил показать на примере с Sinon.
А в ИБ мы используем angular-mocks как ты и написал.
А в ИБ мы используем angular-mocks как ты и написал.
Хорошо, значит вы знаете как удобно, когда angular-mocks бросает ошибку, если произошел запрос, для которого не написан mock.
Sinon в этом случае его пропускает, а это не есть хорошо. Решали как-нибудь эту проблему?
Sinon в этом случае его пропускает, а это не есть хорошо. Решали как-нибудь эту проблему?
В этом проблемы особой нет, имхо, т.к. в любом случае тестируется поведение юнита, который должен не просто бросить запрос, но и получить данные, поэтому более правильно будет все таки проверять, чтобы модуль бросал исключение и перехватывать это в самом тесте.
Кроме того, так как тестируется async-код, то в любом случае надо проверять вызвался ли callback, он либо вызовется, либо упадет по DEFAULT_TIMEOUT_INTERVAL.
Какие с этим проблемы возникали?
Кроме того, так как тестируется async-код, то в любом случае надо проверять вызвался ли callback, он либо вызовется, либо упадет по DEFAULT_TIMEOUT_INTERVAL.
Какие с этим проблемы возникали?
Такой пример: есть сервис по работе с сессией пользователя. Иногда ему нужно сделать запрос на сервер, чтобы узнать нужную информацию, а иногда он может достать её из cookies. Как в таком случае проверить, что, если информация приходит из cookies, то запроса на сервер не случалось?
Лучше быть уверенным, что совершаются только нужные запросы, чтобы не страдала производительность.
Лучше быть уверенным, что совершаются только нужные запросы, чтобы не страдала производительность.
Смотри, смысл в том, что надо как можно тщательнее сделать декомпозицию юнита, чтобы он выполнял что-то одно, а не два действия, как в твоем примере. Те этот сервис вполне можно декомпозировать, допустим на, getFromCookies и getFromAPI. В таком случае, будет немного проще решить эту задачу, проверив, что будет вызываться.
Допустим возьмем Backbone, там все происходит на моделях, те воспользуемся Mock и протестируем работоспособность модели, триггерятся ли на ней события или нет, вызываются ли Spies или еще как то.
Те вполне можно оперирую возможностями Jasmine добиться нужного поведения, если модуль сложно покрыть тестами и отловить его исключения, то надо посмотреть на код, возможно, надо что-то детальнее декомпозировать и разнести по отдельным юнитам и тд.
Вообще по изучаю эту тему на досуге.
Спасибо за вопрос.
Допустим возьмем Backbone, там все происходит на моделях, те воспользуемся Mock и протестируем работоспособность модели, триггерятся ли на ней события или нет, вызываются ли Spies или еще как то.
Те вполне можно оперирую возможностями Jasmine добиться нужного поведения, если модуль сложно покрыть тестами и отловить его исключения, то надо посмотреть на код, возможно, надо что-то детальнее декомпозировать и разнести по отдельным юнитам и тд.
Вообще по изучаю эту тему на досуге.
Спасибо за вопрос.
И снова здравствуйте.
Мне пришлось снова разбираться в вопросе тестов и я нашел еще одно решение для mock-ajax. Может и вас заинтересует:
jasmine.github.io/2.2/ajax.html
В jasmine есть дополнение, которое перехватывает запросы и делает то же самое, что и sinon. Но, поскольку написано специально для jasmine, то лучше встраивается в него и позволяет писать проверки в едином стиле.
Мне пришлось снова разбираться в вопросе тестов и я нашел еще одно решение для mock-ajax. Может и вас заинтересует:
jasmine.github.io/2.2/ajax.html
В jasmine есть дополнение, которое перехватывает запросы и делает то же самое, что и sinon. Но, поскольку написано специально для jasmine, то лучше встраивается в него и позволяет писать проверки в едином стиле.
А как Вам TeamCity? Все ли устраивает? Пользовались им изначально, или перешли с какого-то другого продукта (CI)?
А зачем используется Sinon и Jasmine, если в последнем уже есть mock/stub?
Mocha
Вы работаете с GitFlow, а не Feature Branch. Это очевидно из приведенной вами же ссылки.
баг-репорт
На какой email посылать баги по фронту?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Повышаем стабильность Front-end