1. Jak masz interfejsy to je oznaczaj jakoś np: IEmailService lub MessageAble. Ok, dobra dalej zobaczyłem, że masz impl.
private final String from = "email@gmail.com";
Jeżeli masz pole z klasyfikatorem dostępu final, oznacza się dla ułatwienia za pomocą dużych liter.
private final TodoListDAO todoListDAO;
Dlaczego final? ;d Plus, że znasz DAO no i pojęcie trasnakcji. Na przyszłośc radzę się zainteresować entityMenager znacznie łatwiej się tworzy się zapytania dla connectora w JAVA. Tymbardziej, że przy zawansowanych pytaniach SQL to można normalnie włosy stracić.
Ogólnie ładnie i schludnie. Robiłeś sam czy za pomocą poradnika?
Ale testy za to mi się nie podobają.
public void addUser() throws Exception {
currentSession = userDAO.getSessionFactory().getCurrentSession();
User testUser = new User("Test", "Test123$", "test@test.com");
userDAO.addUser(testUser);
user = userDAO.getUserByName(testUser.getUsername());
assertNotNull(user);
}
Przede wszystkim ta nazwa nic mi nie mówi co jest testowane. Podejść jest parę do typu nazewnictwa. jednym z nich jest takie: user_should_be_not_null.
Po drugie, możesz sobie utworzyć 'setup' bo jakiś miał powiedzmy 3000 testów a w każdym z nich występuje User to te testy trochę dłużej trwały.
Po trzecie, nas za bardzo nie interesuje co ten user sobie tam zawiera, my chcemy sprawdzić czy nasza aplikacja zachowa się zgodnie z założeniami. Czyli możemy zmockować obiekt userDAO. gdy samo pisanie testów jednostkowych bez mockowania jest dość proste to już badanie zachowania za pomocą mock to już trochę trzeba posiedzieć.
Tymbardziej warto się ich nauczyć dla przykładu gdy będziesz musiał napisać testy dla sharePoolSQL powiedzmy dla Oracle, no tam nie utworzysz 15 obiektów wstecz, bo możesz nawet nie wiedzieć jakie to mogą być wartości. Wiem to już jest ekstremalne. Ale taki bardziej przyziemny przypadek to np: badanie działania sesji, np czy użytkownik faktycznie zostanie gdzieś tam przekierowany.
Testuj wszystko nawet najprotsze domeny obiektowe, nie kosztuje cię to za wiele, a będziesz miał pewność , że nagle coś tam na dole się popsuło. Plus załapiesz punkt, że stosujesz podejście TDD.
ublic void crudTask() throws Exception {
TodoList newTodoList = new TodoList("Test", user.getId());
System.out.println(newTodoList);
todoListDAO.addTodoList(newTodoList);
TodoList todoList = todoListDAO.getTodolistsFor(user).get(0);
Task task = new Task("Test", todoList);
todoListDAO.addTask(task);
currentSession.flush();
currentSession.refresh(todoList);
todoList = todoListDAO.getTodolistsFor(user).get(0);
assertTrue("Should be added 1 task but is not", todoList.getTasks().size() == 1);
Task taskToBeChanged = todoList.getTasks().get(0);
String newTaskName = "Changed task name";
todoListDAO.toggleDone((byte) 1, taskToBeChanged.getId());
todoListDAO.changeTaskName(taskToBeChanged.getId(), newTaskName);
currentSession.refresh(taskToBeChanged);
todoList = todoListDAO.getTodolistsFor(user).get(0);
Task retrivedTask = todoList.getTasks().get(0);
assertEquals("Retrived task name should be changed", newTaskName, retrivedTask.getTask());
assertEquals("Retrived task done state should be 1", 1, retrivedTask.getDone());
todoListDAO.deleteTask(todoList.getTasks().get(0).getId());
todoList = todoListDAO.getTodolistsFor(user).get(0);
currentSession.refresh(todoList);
assertTrue("Task should be deleted but is not",todoList.getTasks().size() == 0);
}
I tu masz taki przypadek, zdecydowanie za długi ten test. Po pierwszy jest zły. Jeden test, bada jedną rzecz i wbij to sobie do głowy. Powiedzmy, że mam tych 10000 testów i ten jeden się nie wykona, i na który assert mam patrzeć? tam gdzie się równa , tam gdzie sprawdzam assercję. Nie wiem. Po drugie jest za bardzo zależna.
WAŻNA RZECZ:
Jak już masz jakąś aplikację, warto by było napisać jak należy ją uruchomić!
Przejdżmy jeszcze do JS, bo widzę, że tutaj coś też mamy.
Ok, na początek fajna podpowiedż, jeżeli wywołujesz zdarzenie od rodzica , to te zdarzenie również jest dostępne dla dzieci.
Przykład:
https://codepen.io/shiroUmizake/pen/jGVBYr
Dlaczego tak się dzieje, musisz sam zbadać.
Przez co nie będziesz musiał tych brzydkich (aczkolwiek potrzebnych) foreach. Bo trochę brzydzą kod.
Póżniej ci dołoże kolejne komentarze. xd. Muszę uciekać xd.
