Рефакторинг статического метода / статическое поле для Тестирования
Это ошибка в Android Studio; при некоторых уровнях масштабирования (например, 24% или 9% и т. д.) кнопки масштабирования перестают работать. Одним из исправлений является постоянное изменение типа «Устройство для предварительного просмотра» и поиск того, на котором работают кнопки масштабирования.
Но лучшее исправление , которое сработало для меня, состояло в том, чтобы минимизировать все инструменты внизу, то есть Run, Logcat, TODO, Terminal, Build и другие ... Затем запускаются кнопки масштабирования за работой. Даже если вы снова откроете инструменты, зум продолжит работать.
Просто для проверки решения; Снова откройте один из нижних инструментов (например, Logcat) и нажмите «Масштабировать по размеру экрана (ctl + 0)», скорее всего кнопки зума перестанут работать снова. Просто сверните инструменты снова, и это исправлено.
3 ответа
Только сделать предложение @Robin стратегической модели более конкретным: (Заметьте, что общедоступный API Вашего исходного вопроса остается неизменным.)
public class MyLegacyClass {
private static Strategy strategy = new JNDIStrategy();
public static SomeLegacyClass doSomeLegacyStuff(SomeOtherLegacyClass legacyObj) {
// legacy logic
SomeLegacyClass result = strategy.doSomeStuff(legacyObj);
// more legacy logic
return result;
}
static void setStrategy(Strategy strategy){
MyLegacyClass.strategy = strategy;
}
}
interface Strategy{
public SomeLegacyClass doSomeStuff(SomeOtherLegacyClass legacyObj);
}
class JNDIStrategy implements Strategy {
private static final String jndiName = "java:comp/env/jdbc/LegacyDataSource";
public SomeLegacyClass doSomeStuff(SomeOtherLegacyClass legacyObj) {
// do stuff using jndiName
}
}
... и тест JUnit. Я не большой поклонник необходимости сделать это обслуживание установки/разрушения, но это - неудачный побочный эффект наличия API на основе статических методов (или Одиночные элементы в этом отношении). То, что мне действительно нравится приблизительно этот тест, является им, не использует JNDI - это хорошо потому что (a) это будет работать быстро и (b) модульный тест должен только тестировать бизнес-логику в doSomeLegacyStuff () метод так или иначе, не тестируя фактический источник данных. (Между прочим, это предполагает, что тестовый класс находится в том же пакете как MyLegacyClass.)
public class MyLegacyClassTest extends TestCase {
private MockStrategy mockStrategy = new MockStrategy();
protected void setUp() throws Exception {
MyLegacyClass.setStrategy(mockStrategy);
}
protected void tearDown() throws Exception {
// TODO, reset original strategy on MyLegacyClass...
}
public void testDoSomeLegacyStuff() {
MyLegacyClass.doSomeLegacyStuff(..);
assertTrue(..);
}
static class MockStrategy implements Strategy{
public SomeLegacyClass doSomeStuff(SomeOtherLegacyClass legacyObj) {
// mock behavior however you want, record state however
// you'd like for test asserts. Good frameworks like Mockito exist
// to help create mocks
}
}
}
Я думаю, что лучшее решение здесь, связывают это JNDI с локальным
Унаследованный код использует jndiName как этот:
DataSource datasource = (DataSource)initialContext.lookup(DATASOURCE_CONTEXT);
Так, решение здесь, связывают локальное (или независимо от того, что у Вас есть для Вас данные тестирования) в JNDI как этот:
BasicDataSource dataSource = new BasicDataSource();
dataSource.setDriverClassName(System.getProperty("driverClassName"));
dataSource.setUser("username");
dataSource.setPassword("password");
dataSource.setServerName("localhost");
dataSource.setPort(3306);
dataSource.setDatabaseName("databasename");
И затем привязка:
Context context = new InitialContext();
context.bind("java:comp/env/jdbc/LegacyDataSource",datasource);
Или что-то подобное, надейтесь, что это помогает Вам.
Удачи!
Осуществите рефакторинг код для использования внедрения зависимости. Затем используйте Вас, предпочел, чтобы платформа DI (Spring, Guice...) ввела Ваши ресурсы. Это поможет переключиться между объектами ресурса и стратегиями во времени выполнения.
В этом случае можно ввести источник данных.
Править: На основе Вашего нового ограничения можно выполнить то же самое при помощи стратегической модели для установки источника данных во времени выполнения. Можно, вероятно, просто использовать файл свойств для различения который стратегия создать и предоставить источник данных. Это не потребовало бы никакой новой платформы, Вы просто будете рукой, кодирующей ту же основную функциональность. Мы использовали эту точную идею с ServiceLocator для предоставления ложного источника данных при тестировании за пределами Java контейнера EE.