Skip to content

Instantly share code, notes, and snippets.

@kawazoe
Last active August 29, 2015 14:11
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kawazoe/58399d28f11920a0ee33 to your computer and use it in GitHub Desktop.
Save kawazoe/58399d28f11920a0ee33 to your computer and use it in GitHub Desktop.
Open letter to the github FurAffinity/phoenix project.

BDD / TDD - First stop for a public facing API

Based on what you have mentioned in issue #8 , I would recommend you to put more time in moving toward a TDD or BDD model.

From my own experience in writing and consuming public APIs, the first place where developers tends to look for when they need information about an API is in the documentation and the tests. Those tests are not only the best way to know what are the features and limitations of your API, they are also the best way to know how to use your API. With unit tests, you set a standard for third parties when it comes to consuming your API.

Considering the current state of your code, you should gear up toward more unit testing as soon as possible. Your current architecture, with a goal of proper testing in mind, is mediocre at best and will causes you massive headaches when you will finally start testing. There is already a major re-factoring work that needs to be done before even thinking about doing proper unit testing. Postponing this will only cost you an exponential amount of time and effort as time goes.

Since there isn't much code yet in your application, it is a great time to start modularize and layer the various components in your code base using techniques like the Micro Service Architecture. Those changes will greatly simplify testing the various components of your application and will enable greater agility from your team.

@erickgirard
Copy link

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment