The document discusses test-driven development (TDD) and test-last development (TLD). It explains that TLD involves adding tests to existing legacy code, starting with the easiest parts to test, while not changing the production code. TDD involves writing tests before developing new code to specify requirements. The document demonstrates applying TLD and TDD to a registration form code example, separating testable logic into independent functions, adding tests, and refactoring to satisfy new requirements and prevent tests from breaking. Benefits of TLD and TDD mentioned include feeling less anxious and stressed.

1. How Test Newbie began testing

2. 01 Story about how I did
REAL Benefits I felt while doing TLD & TDD
▪ TLD (Test Last Development)
▪ TDD (Test Driven Development)
CONTENTS
02

3. In this presentation, “Test” means unit test only.
The language is JavaScript.
The test framework is Jest.
There's a React code, but it doesn't matter if you don't know it.
NOTICE

4. Story about.
How I did.

5. 1-1
What is the TDD and TLD?

6. Red Green
Refactor
(Fail) (Success)
(Success)

7. Red Green
Refactor
(Fail) (Success)
(Success)
Write the functional code until the test passes.

8. Red Green
Refactor
(Fail) (Success)
(Success) Refactor both new and old code
to make it well structured.

9. Red Green
Refactor
(Fail) (Success)
(Success)

10. Red Green
Refactor
(Fail) (Success)
(Success)
TDD – Test Driven Development

11. TDD TLD
Red Green
Refactor
(Fail) (Success)
(Success)
No
code
Red Green
Refactor
(Fail) (Success)
(Success)
Wrong
code

12. TDD
Red Green
Refactor
(Fail) (Success)
(Success)
No
code
The Red step in TDD means that
there is no implementation code.
This means that it hasn’t been
implemented yet.

13. TLD
Red Green
Refactor
(Fail) (Success)
(Success)
Wrong
code
The Red step in TLD means that
there is(are) a bug(s).
This means that there is a wrong code.

14. 1-2
* TLD
Adding tests to legacy code

15. Code easy
to test
Code hard
to test
Production code
Pure function
External Dependency
Start with code that's already made easy to test
ex. utility, helper

16. // YY. M. DD.-> YYMMDD
export function formatDateForQueryString(dateString) {
const splitArray = dateString.split('.’);
splitArray.map((el, i, arr) => {
arr[i] = el.replace(/ /gi, '').length === 1 ? '0' + el : el;
});
return result.join('').replace(/ /gi, '');
}
Code easy
to test
Function that converts a string in format 'YY. M. DD. ' to a string in format 'YYMMDD'
// dateHelper.test.js
describe('formatDateForQueryString function', () => {
describe(‘converts a string in format “YY. M. DD.”', () => {
test(‘to a string in “YYMMDD”.', () => {
const actual = formatDateForQueryString('18. 1. 10.');
expect(actual).toBe('180110');
});
});
});
Don’t change production codes

17. // YY. M. DD.-> YYMMDD
export function formatDateForQueryString(dateString) {
const splitArray = dateString.split('.’);
splitArray.map((el, i, arr) => {
arr[i] = el.replace(/ /gi, '').length === 1 ? '0' + el : el;
});
return result.join('').replace(/ /gi, '');
}
Code easy
to test
// dateHelper.test.js
describe('formatDateForQueryString function', () => {
describe(‘converts a string in format “YY. M. DD.”', () => {
test(‘to a string in “YYMMDD”.', () => {
const actual = formatDateForQueryString('18. 1. 10.');
expect(actual).toBe('180110');
});
});
}); Don’t change the test codes
Function that converts a string in format 'YY. M. DD. ' to a string in format 'YYMMDD'

18. // YY. M. DD.-> YYMMDD
export function formatDateForQueryString(dateString) {
const splitArray = dateString.split('.’);
splitArray.map((el, i, arr) => {
arr[i] = el.replace(/ /gi, '').length === 1 ? '0' + el : el;
});
return result.join('').replace(/ /gi, '');
}
Code easy
to test
export function formatDateForQueryString(dateString) {
return `${dateString} `
.split('. ')
.map(x => (x.length === 1 ? `0${x}` : x))
.join('');
}
The refactoring should be limited to the extent that the test is not broken.
Refactor

19. Ex. Maybe almost?
Separate only those codes that are easy to test from those that are made difficult to test.
Code easy
to test
Code hard
to test
Production code
Parts include high-value business logic
Buggy code (current, not past)
Low coupling and complex logic*
Where can I find it?
*Low or no external dependency (independent environment)
and business logic is complex (Replace username to email, etc.)

20. Code hard
to test
easy
hard
easy
Overall flow
Find the testable code, Separate them, Add test code, And Refactor
Refactor
Red
Green
or

21. class RegistrationFormContainer extends Component {
/ * (Omitted) Methods on modal behavior * /
handleSubmit = async () => {
const { validValues } = this.props.form;
const phone = validValues.phone
? '+82' + validValues.phone.slice(1)
: null;
const command = {
username: validValues.username || validValues.email,
email: validValues.email,
phone: phone,
};
try {
await postRegisterRequest(command);
this.closeModal();
} catch (err) {
Modal.error({ /* ... */ });
}
};
render() { /* ... */ }
}
}
Code hard
to test
* React code
This contains important business logic.
Why this code is difficult to test
• API request
• Different UI depending on the result of the response
Only separate testable parts
 API request

22. function formatRegisterCommand() {
const { validValues } = this.props.form;
const phone = validValues.phone
? '+82' + validValues.phone.slice(1)
: null;
const command = {
username:
validValues.username || validValues.email,
email: validValues.email,
phone: phone,
};
return command;
}
export default formatRegisterCommand;
import formatRegisterCommand /* ... */
describe('formatRegisterCommand function ', () => {
test(‘does not throw error.', () => {
expect(formatRegisterCommand).not.toThrowError();
});
});
UTF-8 LF JavaScript React Prettier:
formatRegisterCommand.js formatRegisterCommand.test.js

23. function formatRegisterCommand() {
const { validValues } = this.props.form;
const phone = validValues.phone
? '+82' + validValues.phone.slice(1)
: null;
const command = {
username:
validValues.username || validValues.email,
email: validValues.email,
phone: phone,
};
return command;
}
export default formatRegisterCommand;
import formatRegisterCommand /* ... */
describe('formatRegisterCommand function ', () => {
test(‘does not throw error.', () => {
expect(formatRegisterCommand).not.toThrowError();
});
});
UTF-8 LF JavaScript React Prettier:
formatRegisterCommand.js formatRegisterCommand.test.js
Removes framework-dependent (=external dependency) code

24. function formatRegisterCommand(validValues={}){
const phone = validValues.phone
? '+82' + validValues.phone.slice(1)
: null;
const command = {
username:
validValues.username || validValues.email,
email: validValues.email,
phone: phone,
};
return command;
}
export default formatRegisterCommand;
import formatRegisterCommand /* ... */
describe('formatRegisterCommand function ', () => {
test(‘does not throw error.', () => {
expect(formatRegisterCommand).not.toThrowError();
});
});
UTF-8 LF JavaScript React Prettier:
formatRegisterCommand.js formatRegisterCommand.test.js
Make it an independent function that is not affected externally

25. function formatRegisterCommand(validValues={}){
const phone = validValues.phone
? '+82' + validValues.phone.slice(1)
: null;
const command = {
username:
validValues.username || validValues.email,
email: validValues.email,
phone: phone,
};
return command;
}
export default formatRegisterCommand;
/* ... */
describe('returns a command', () => {
const param = {
username: 'user',
email: 'user@email.com',
phone: '01012345678',
agreement: [true, true, true],
};
describe('whose username property should be', () => {
test('the same as the username of the argument.’, () => {
const actual = formatRegisterCommand(param);
expect(actual.username).toBe(param.username);
});
});
});
UTF-8 LF JavaScript React Prettier:
formatRegisterCommand.js formatRegisterCommand.test.js
Add a spec about the return value

26. Develop new code with TDD.
1-3

27. I received additional business requirements.
"A user must agree all the terms to sign up."

28. /* ... */
describe('whose agreement property should be', () => {
test('return false when any of the arguments are false',()=> {
const actual = formatRegisterCommand({
...param,
agreement: [true, true, false],
});
expect(actual).toBe(false);
});
});
/* ... */
UTF-8 LF JavaScript React Prettier:
formatRegisterCommand.js formatRegisterCommand.test.js
function formatRegisterCommand(source = {}) {
const { username, email, phone } = source;
return {
username: username || email,
email,
phone: phone ? `+82${phone.slice(1)}` : null,
};
}
export default formatRegisterCommand;

29. /* ... */
describe('whose agreement property should be', () => {
test('return false when any of the arguments are false',()=> {
const actual = formatRegisterCommand({
...param,
agreement: [true, true, false],
});
expect(actual).toBe(false);
});
});
/* ... */
UTF-8 LF JavaScript React Prettier:
formatRegisterCommand.js formatRegisterCommand.test.js
function formatRegisterCommand(source = {}) {
const { username, email, phone } = source;
if (source.agreement.some(agree => !agree)) {
return false;
}
return {
username: username || email,
email,
phone: phone ? `+82${phone.slice(1)}` : null,
};
}
export default formatRegisterCommand;
if (source.agreement.some(agree => !agree)) {
return false;
}

30. Summarize
1-4

31. 1. Adding tests to legacy code (+Refactor)
2. Develop new code with TDD.
HOW: Follows below cycle
Separate
as function
Refactor
Add test
code
WHAT: Codes easy to test
- Parts includes high-value business logic
- The spot where the bug was found (formerly X)
- Low coupling and complex logic
TLD
1. Add tests to code that is already easy to test.
2. Make your code easy to test, and then test.
TDD
- Where to add new features

32. REAL Benefits.
I felt while doing TLD & TDD.

33. Less anxious, Less stress
Things I really felt while doing TEST.

34. /* ... */
describe('formatRegisterCommand function', () => {
test(‘does not throw error.', () => {
expect(formatRegisterCommand).not.toThrowError();
});
});
describe(‘whose agreement property should be', () => {
test('return false when any of the arguments are fal
=> {
const actual = formatRegisterCommand({
...param,
agreement: [true, true, false],
});
expect(actual).toBe(false);
});
});
/* ... */
UTF-8 LF JavaScript React Prettier:
formatRegisterCommand.js formatRegisterCommand.test.js
function formatRegisterCommand(source = {}) {
const { username, email, phone } = source;
if (source.agreement.some(agree => !agree)) {
return false;
}
return {
username: username || email,
email,
phone: phone ? `+82${phone.slice(1)}` : null,
};
}
export default formatRegisterCommand;
if (source.agreement.some(agree => !agree)) {
return false;
}
FAIL src/business/formatRegisterCommand.test.js
● formatRegisterCommand function › does not throw error.
expect(function).not.toThrowError()
Expected the function not to throw an error.
Instead, it threw:
TypeError: Cannot read property 'some' of undefined
at formatRegisterCommand (src/business/formatRegisterCommand.js:9:17)
/* ... */
formatRegisterCommand function
✓ does not throw error.
return command
UTF-8 LF JavaScript React Prettier:

35. The test code makes me to find the
code smell pretty often.
Things I really felt while doing TEST.
Improve the design of code

36. PASS src/business/formatRegisterCommand.test.js
formatRegisterCommand function
✓ does not throw error.
return command
whose username property should be
✓ equal to username value of argument.
✓ equal to email value of argument when username value is falsy value.
whose email property should be
✓ equal to email value of argument.
whose phone property should be
✓ the value of phone property of argument that changed the first 0 to ..
whose agreement property should be
✓ return false when any of the arguments are false.
For example,

37. PASS src/business/formatRegisterCommand.test.js
formatRegisterCommand function
✓ does not throw error.
return command
whose username property should be
✓ equal to username value of argument.
✓ equal to email value of argument when username value is falsy value.
whose email property should be
✓ equal to email value of argument.
whose phone property should be
✓ the value of phone property of argument that changed the first 0 to ..
whose agreement property should be
✓ return false when any of the arguments are false.
For example,
2 Type of return value.
- command object
- false
2 Responsibilities.
- Decide whether user can join
- Format input values to command object

38. formatRegisterCommand.js
function formatRegisterCommand(source = {}) {
const { username, email, phone } = source;
const agreement = source.agreement || [];
if (agreement.some(agree => !agree))
return false;
return {
username: username || email,
email,
phone: phone
? `+82${phone.slice(1)}`
: null,
};
}
export default formatRegisterCommand;
UTF-8 LF JavaScript React Prettier:

39. I realize how bad design skills I have.
So I'm interested in stable code and good design.
Motivation for learning
Things I really felt while doing TEST & TDD.

40. Bug tracking time is significantly reduced.
Improve development productivity
* Time saved without testing ≤ Time to fix a bug from not tested code
* It’s my subjective feeling. No objectivity.
Things I really felt while doing TEST & TDD.

41. I've found some loopholes in business logic *in advance.
Improve project productivity
*Before I (or we) start coding
Things I really felt while doing TDD.

42. TDD controls that I don’t do more than one thing at a time.
It makes me focus more on what I have to do right now.
Concentration is improved
Things I really felt while doing TDD.

43. Original article: https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847/
RIP TDD: The article criticizes DHH's article, "TDD is dead."
In this article, Kent Beck mentions the benefits of TDD.
-
Over-engineering.
I have a tendency to "throw in" functionality I "know" I'm
"going to need". Making one red test green (along with the
list of future tests) helps me implement just enough. I need
to find a new way to stay focused.

44. THANK YOU