background: -webkit-linear-gradient(bottom, #87C03B, #98D647);background-image: -webkit-linear-gradient(bottom, #87C03B, #98D647);
Нормальна ли схема с единой точкой входа
ведь, если количество модулей перевалит за 10
вешать события на элементы
Или стоит создать отдельную страницу, на которой будут запускаться тесты mocha на основе уже собранного JS проекта?
Пока я вижу следующую схему: mocha + jsdom
если моя функция не предназначена для работы с DOM — я должен снова вернуться к unit-тестам.
Имеет ли вообще смысл тестировать, скажем так, такой примитивный код?
Возможно у кого-то завалялся репозиторий с похожим кейсом?
someObject = null //не знаю можно ли писать в cs var поэтому так
Promise.resolve()
.then(@getObjectDescription.bind(@))
.then(
(so) ->
someObject = so
)
.then(@getSomeSpecialFieldValue.bind(@))
.then(
(value) ->
someObject.special_field = value
return someObject
)
.then(
(someObject) ->
data = new FormData()
data.append('field', someObject.field)
data.append('special_field', someObject.special_field)
options =
method: 'post'
body: data
return options
)
.then(@execute.bind(@, 'rest.api.method'))With PDO_MYSQL you need to remember about the PDO::ATTR_EMULATE_PREPARES option.
The default value is TRUE, like
$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,true);
This means that no prepared statement is created with $dbh->prepare() call. With exec() call PDO replaces the placeholders with values itself and sends MySQL a generic query string.
The first consequence is that the call $dbh->prepare('garbage');
reports no error. You will get an SQL error during the $dbh->exec() call.
The second one is the SQL injection risk in special cases, like using a placeholder for the table name.
The reason for emulation is a poor performance of MySQL with prepared statements. Emulation works significantly faster.
