TDD Design Testable Code Login

1. Testing and Testable code Paweł Szulc http://paulszulc.wordpress.com [email_address]

3. Java Developer (currently Wicket+Spring+JPA)

5. E-mail: paul.szulc@gmail.com

9. Testing

11. Testing

12. Testable code

14. Testing

17. Testing

20. Testing

29. Code not maintainable – twice more effort

37. It's not about testing, it's about requirements and design

40. Large tests and relatively high coverage are just positive side effects

42. TDD Architect

44. TDD Architect ” Test Driven Development is like sex. If you don't like it, you probably ain't doing it right.”

47. Should not login for incorrect login

48. Should not login for incorrect password

49. Not logged in user is an 'guest user'

50. Guest user has login 'Guest'

53. Should not login fo...

60. User need to have login and password fields

64. Getters and setters!

69. Equals and hashCode methods for equality

75. Testing and testable code @Test public void testUserCreation() throws Exception { User user = new User(); }

76. Testing and testable code @Test public void testUserHasLoginAndPassword() throws Exception { User user = new User(); user.setLogin("login"); user.setPassword("password"); assertEquals("login", user.getLogin()); assertEquals("password", user.getPassword()); }

77. Testing and testable code @Test public void testEqualsMethodValidForSameLogin() throws Exception { User user1 = new User(); user1.setLogin("login"); User user2 = new User(); user2.setLogin("login"); assertEquals(user1, user2); }

78. Testing and testable code @Test public void testEqualsMethodReturnsFalseForDifferentLogin() throws Exception { User user1 = new User(); user1.setLogin("login"); User user2 = new User(); user2.setLogin("login2"); assertFalse(user1.equals(user2)); }

79. Testing and testable code @Test public void testEqualsHashCodeConstract() throws Exception { User user1 = new User(); user1.setLogin("login"); User user2 = new User(); user2.setLogin("login"); assertTrue(user1.equals(user2)); assertEquals(user1.hashCode(),user2.hashCode()); }

80. Testing and testable code public class User { private String login, password; public User() { } public String getLogin() { return login; } public void setLogin(String login) { this.login = login; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; User user = (User) o; if (!login.equals(user.login)) return false; return true; } public int hashCode() { return login.hashCode(); } } Design you get:

91. Testing and testable code … the test should really looked like this: @Test public void shouldLoginForCorrectLoginAndPassword() throws Exception{ // given String login = "login"; String password = "password"; dao.persist(new User(login,password)); // when User user = service.logIn(login, password); // then assertEquals(login, user.getLogin()); assertEquals(password, user.getPassword()); }

92. Testing and testable code public class User { private String login, password; public User(String login, String password) { this.login = login; this.password = password; } public String getLogin() { return login; } public String getPassword() { return password; } } Design you get:

93. Testing and testable code public class User { private String login, password; public User() { } public String getLogin() { return login; } public void setLogin(String login) { this.login = login; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; User user = (User) o; if (!login.equals(user.login)) return false; return true; } public int hashCode() { return login.hashCode(); } } public class User { private String login, password; public User(String login, String password) { this.login = login; this.password = password; } public String getLogin() { return login; } public String getPassword() { return password; } }

95. Smallest change in your code make a lot of tests fail, even if that change isn't caused be change of requirements

97. Created design based on experience only.

98. Design is complex, not maintainable

106. Is 75% code coverage good enough?

110. Create basic architecture using interfaces

112. Create basic architecture using interfaces

113. Start writing tests while implementing previously designed interfaces

116. Bigger chances that code will do what client wants (requirements)

117. Will not stand a chance when the requirements change (design)

119. Bigger chances that code will do what client wants (requirements)

120. Will not stand a chance when the requirements change (design)

121. Again: not a TDD practice!

124. Run all tests and see the new one failing

125. Add some code

126. Run all tests and see the new one succeeds

127. Refactor

129. Add test

131. Add some code

133. Refactor

135. Add test that represents the requirement

137. Add some code

139. Refactor

143. Add some code

145. Refactor whenever design is getting ugly

149. Add some code

160. Testing and testable code The BIG Problem...

161. Testing and testable code The BIG Problem... You still simply ain't gonna use TDD.

162. Testing and testable code The BIG Problem... You still simply ain't gonna use TDD. … whatever the reasons are.

167. Bugs Driven Tests

171. Write test that checks whether the bug is fixed

173. Write test that checks whether th bug is fixed

174. Test should fail

178. Fix the bug

182. Fix the bug

183. Test should succeed

185. No bugs regression

189. 80% of importance

196. Code might be not testable and so writing tests hard or even impossible

203. Promotes good design and good quality code

206. Declarative

209. Declarative

210. Easy to read

213. Declarative

214. Easy to read

215. Easy to maintain

224. A and B does not know anything about each other

227. Test are not isolated, even if they look like they are ” You may not have thought of it this way before, but whenever you use static state, you’re creating secret communication channels and not making them clear in the API.”

229. Global state often prevents tests from being able to run in parallel

232. Static method instantiating

237. Only exception: no state (rarely happens)

240. Only exception: no state (rarely happens)

241. Tests: methods like reset()

244. They hide from developers true intentions of the implementation

246. They hide from developers true intentions of the implementation

247. Far from ”clean code that talks”

252. communicating with other services

253. logic to set up its own state

256. communicating with other services

258. Unable to inject test mocks

260. Collaboration graph

266. Declarative style of programming

271. http://misko.hevery.com/code-reviewers-guide/

275. TDD is about design and requirements

278. More often you use TDD more addicting it becomes

282. If used efficiently, you develop your code with good pace, code is readable and maintainable. You rarely hear about regression bugs.

287. Bugs Driven Testing – good starting point

292. Bugs Driven Testing – good starting point

293. Testable code: clean code that talks

294. Testing and testable code Q&A

TDD Design Testable Code Login

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie TDD Design Testable Code Login

Ähnlich wie TDD Design Testable Code Login (20)

Mehr von Pawel Szulc

Mehr von Pawel Szulc (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

TDD Design Testable Code Login