README.md

kata-birthday-greetings

TDD Kata in Java inspired by Matteo Vaccari

1. I implemented it following baby steps
2. Of course using the TDD cycle: Red --> Green --> Refactor
3. My approach to write functional tests for TDD can be found here is a diagram showing how tests interacts only with Domain Objects and never with external dependencies.

Object Oriented Design and other heuristics

TDD does not mean you will end up with a good design. A good designer will likely come up with a good design. That said, I've listed couple of heurists:

1. Avoid usage of null, instead use Null Object pattern (you can see this on class NullEmployee ).

2. Always refactor with all tests in Green .

3. Always run all tests when you're refatoring.

4. Test should have full control of everything (time, date, test data, etc). Please check class BirthdayGreetingsTestObjects and how it is used on Tests.

5. Never hardcode today() or any time/date inside your classes. It is better to pass it as parameter. Please check method greetOn(LocalDate date) in class BirthdayGreeting . Even test objects you can make them flexible on time/date like method employeeSystemOfRecordsWithTwoEmployeeBornOn(LocalDate date)

6. Pass dependencies in constructors. Please check constructor BirthdayGreeting(EmailSystem emailSystem, EmployeeSystem employeeSystemOfRecords)

7. Use names which represents better its meaning e.g: EmployeeSystemOfRecord is prefered over EmployeeRepository and BirthdayGreeting is prefered over BirthdayService

8. Make your classes to depend on Interfaces

 public BirthdayGreeting(EmailSystem emailSystem, EmployeeSystem employeeSystemOfRecords){
        this.emailSystem = emailSystem;
        this.employeeSystemOfRecords = employeeSystemOfRecords;
  }

9. Avoid Mocking frameworks as much as you can. Instead use a technique shown in class BirthdayGreetingsTestObjects

public EmailSystem successEmailSystemWithTrue() { return (email) -> {return true;}; }
public EmailSystem successEmailSystemWithFalse() { return (email) -> {return false;}; }

10. Avoid naming classes like YYYManager, YYYController, EmployeeValidator,

11. You will get the most of TDD if you create functional tests (not unit tests nor integration tests).

• Unit tests are very fine grained (e.g: EmployeeTest where you will test only Employee class isoleted).
• Integration tests depend on I/O and usually are quite slow and unpredictable.

Both (unit and integration tests) could be important for your project, but they are not part of pure hardcore TDD :-)

12. Rember a good developer is also a good tester. Be proffesional and responsible, always develop robust software following best practices. It will save you time, headaches, pager duties, issues in production, etc.

Be in the zone

• Music to keep you in the zone radio de x-team

References

In English

• Adrian Bolboaca blog with tons of good quality videos doing TDD.

In Spanish

• Diseño ágil con TDD
• 10 Pines University
• Implementando Exception en Ruby
• Aprendiendo Smalltak

Authors

• Matias Tripode - My profile on Linkedin and on twitter

License

This project is licensed under the MIT License - see the LICENSE.md file for details

Acknowledgments

• Hernan Wilkinson and 10pines for sharing such amazing knowledge