Skip to content

Latest commit

 

History

History
74 lines (49 loc) · 4.2 KB

README.md

File metadata and controls

74 lines (49 loc) · 4.2 KB

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 #f03c15 --> Green #c5f015 --> 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 #c5f015.

  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;
  }
  1. 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;}; }
  1. Avoid naming classes like YYYManager, YYYController, EmployeeValidator,

  2. 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 :-)

  1. 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

References

In English

In Spanish

Authors

License

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

Acknowledgments