/trip-service-kata

Kata for a legacy code hands-on session. The objective is to write tests and refactor the given legacy code.

Primary LanguageABAP

Trip Service Kata

Kata for legacy code hands-on session. The objective is to test and refactor the legacy TripService class.

The end result should be well-crafted code that express the domain.

You can watch the video with my solution. Although quite long, I explain my whole thought process while writting tests, how I break dependencies, the reasons for refactoring and re-desining the code (tests and production code), and why certain steps are important. I also cover how often I commit and why I do it.

The video is full of tips and tricks that can be used in any language.

Business Rules

Imagine a social networking website for travellers:

  • You need to be logged in to see the content
  • You need to be a friend to see someone else's trips
  • If you are not logged in, the code throws an exception

Exercise Rules

  • Our job is to write tests for the TripService class until we have 100% coverage
  • Once we have 100% coverage, we need to refactor and make the code better.
  • At the end of the refactoring, both tests and production code should clearly describe the business rules

Exercise Constraints

  • We cannot manually change production code if not covered by tests, that means:
    • We cannot type type of the TripService class while still not covered by tests
  • If we need to change the TripService class in order to test, you can do so using automated refactorings (via IDE)
  • We CANNOT change the public interface of TripService, that means:
    • We cannot change its constructor
    • We cannot change the method signature
    • Both changes above might cause other classes to change, which is not desirable now
  • We CANNOT introduce state in the TripService
    • TripService is stateless. Introducing state may cause multi-thread issues

Extracted rules from here