Лучший способ протестировать приложение Доступа MS?
Посмотрите на этот пример Plnkr
Переменная this сильно отличается timesCalled с каждым нажатием кнопки увеличивается только на 1. Ответ на мой личный вопрос:
.click( () => { } )
и
.click(function() { })
создают одинаковое количество функции при использовании в цикле, как вы можете видеть из подсчета Guid в Plnkr.
8 ответов
Я ценил ответы knox и david. Мой ответ будет где-нибудь между их: просто сделайте формы, которые не должны быть отлажены !
я думаю, что формы должны исключительно использоваться в качестве, что они в основном, имея в виду графический интерфейс [только 1 112] , означая здесь, что они не должны быть отлажены! Задание отладки тогда ограничено Вашими модулями VBA и объектами, который намного легче обработать.
существует, конечно, естественное стремление для добавления кода VBA к формам и/или средствам управления, особенно когда Доступ предлагает Вам их большие "после Обновления" и "на изменении" события, но я определенно советую Вам не помещать любую форму или управлять определенным кодом в модуле формы. Это делает дальнейшее обслуживание и обновление очень costy, где Ваш код разделяется между модулями VBA и модулями форм/средств управления.
Это не означает, что Вы не можете больше использовать этот AfterUpdate событие! Просто поместите стандартный код в конечном счете, как это:
Private Sub myControl_AfterUpdate()
CTLAfterUpdate myControl
On Error Resume Next
Eval ("CTLAfterUpdate_MyForm()")
On Error GoTo 0
End sub
, Где:
-
CTLAfterUpdateстандартная процедура, работает каждый раз, когда управление обновляется в форме -
CTLAfterUpdateMyForm, конкретная процедура, работает каждый раз, когда управление обновляется на MyForm
, у меня есть тогда 2 модуля. Первый -
-
utilityFormEvents
, где у меня будет свой CTLAfterUpdate универсальным событием
, второй -
-
MyAppFormEvents
содержащий определенный код всех определенных форм приложения MyApp и включая процедуру CTLAfterUpdateMyForm. Конечно, CTLAfterUpdateMyForm не мог бы существовать, если нет никакого определенного кода для выполнения. Поэтому мы поворачиваемся "На ошибке" для "возобновления затем"...
Выбор такого универсального решения означает много. Это означает достижение высокого уровня нормализации кода (значение безболезненного обслуживания кода). И то, когда Вы говорите, что у Вас нет определенного для формы кода, это также означает, что модули формы полностью стандартизированы, и их производство может быть , автоматизировало : просто скажите, какими событиями Вы хотите управлять на уровне формы/управления и определить Вашу универсальную терминологию / терминологию конкретных процедур.
Запись Ваш код автоматизации, раз и навсегда.
требуется несколько дней работы, но это дает захватывающие результаты. Я использовал это решение в течение прошлых 2 лет, и это - ясно правильное: мои формы полностью и автоматически созданы с нуля с "Таблицей Форм", связаны с "Таблицей Средств управления".
я могу тогда провести свое время, работая над конкретными процедурами формы, если таковые имеются.
нормализация Кода, даже с Доступом MS, является долгим процессом. Но это действительно стоит боли!
Другое преимущество Доступ, являющийся приложением COM, - то, что можно создать приложение.NET, чтобы выполнить и протестировать приложение Доступа через Автоматизацию . Преимущество этого состоит в том, что тогда можно использовать более мощную среду тестирования такой в качестве , NUnit для записи автоматизированный утверждает тесты против приложения Доступа.
Поэтому, если Вы являетесь опытными или в C# или в VB.NET, объединенном с чем-то как NUnit тогда, можно более легко создать большее тестовое покрытие для приложения Доступа.
Я разработал бы приложение для имения как можно большей работы, сделанной в запросах и в vba подпрограммах так, чтобы тестирование могло быть составлено из заполнения тестовых баз данных, рабочих наборов производственных запросов и vba против тех баз данных и затем рассмотрения вывода и сравнения, чтобы удостовериться, что вывод хорош. Этот подход не тестирует GUI, очевидно, таким образом, Вы могли увеличить тестирование с рядом сценариев тестирования (здесь, я имею в виду как документ слова, в котором говорится открытая форма 1, и нажмите управление 1), которые вручную выполняются.
Это зависит от объема проекта как уровень автоматизации, необходимой для аспекта тестирования.
Если Вашей заинтересованной тестированием Вашего приложения Доступа на более детализированном уровне конкретно сам код VBA тогда Облегченная Единица VB является большая платформа поблочного тестирования с этой целью.
Я не попробовал это, но Вы могли попытаться к , публикуют Ваши формы доступа как веб-страницы доступа к данным к чему-то как sharepoint или так же, как веб-страницы и затем используют инструмент такой в качестве селен для управления браузером с комплектом тестов.
, Очевидно, это не столь идеально как управление кодом непосредственно через модульные тесты, но это может получить Вас часть пути. удача
Доступ является приложением COM. Используйте COM, не Windows API. протестировать вещи в Доступе.
лучшей Тестовой средой для Приложения Доступа является Доступ. Все Ваши Формы/Отчеты/Таблицы/Код/Запросы доступны, существует язык сценариев, подобный Тесту MS (Хорошо, Вы, вероятно, не помните Тест MS), существует среда базы данных для содержания Ваших сценариев тестирования и результатов испытаний, и навыки, которые Вы создаете здесь, передаваемы к Вашему приложению.
Страницы доступа к данным были удержаны от использования MS в течение достаточно долгого времени, и никогда действительно работали во-первых (они зависели от Виджетов Office, устанавливаемых, и работали только в IE, и только плохо тогда).
Это верно, что Средства управления доступом, которые могут получить фокус только, имеют дескриптор окна, когда у них есть фокус (и те, которые не могут получить фокус, такой как маркировки, никогда не иметь дескриптор окна вообще). Это делает Доступ особенно несоответствующим окну управляемый дескриптором, тестируя режимы.
Действительно, я подвергаю сомнению, почему Вы хотите сделать этот вид тестирования в Доступе. Это звучит мне как Ваша основная догма Экстремального программирования, и не все принципы, и методы XP могут быть адаптированы для работы с приложениями Доступа - квадратный штепсель, круглая дыра.
Так, отступите и спросите себя, что Вы пытаетесь выполнить и полагать, что Вы, возможно, должны использовать совершенно другие методы, чем те, которые основаны на подходах, которые просто не могут работать в Доступе.
Или допустимо ли такое автоматизированное тестирование вообще или даже полезно с приложением Доступа.
Здесь есть хорошие предложения, но я удивлен, что никто не упомянул централизованную обработку ошибок. Вы можете получить надстройки, которые позволяют быстро создавать функции / подшаблоны и добавлять номера строк (я использую MZ-инструменты). Затем отправьте все ошибки в одну функцию, где вы сможете их зарегистрировать. Вы также можете затем разбить все ошибки, установив одну точку останова.