Write Tests First, Write Code Second

Our group project, “Phrogress” relies heavily in phabricator data. These data can be retrieved by using phabricator conduit API. To make things simpler, we would like to implement our own API wrapper to encapsulate conduit API. The wrapper will be implemented using Ruby on Rails (RoR) and placed on backend side, connecting frontend side of our application to phabricator data.

To ensure the correctness of our own endpoints, unit test is required throughout every aspect of the API wrapper. Moreover, TDD (Test Driven Development) is a mandatory for all groups in PPL class.


wait a minute, what is TDD?

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.

simply taken from Wikipedia

TDD thinks that good codes are started with a good test. Programmers are insisted to create test before writing any codes. So, under TDD, we must have a promise to write test first, write codes second

“One bad programmer can easily create two new jobs a year.” – David Parnas

Okay, okay, so now, how will you test?

We will use Ruby on Rails on backend side of our application and for testing purpose, RoR has its own testing framework, called Test::Unit. Test::Unit is covered in RoR documentation nicely but our team decided to use something else. Our test framework will be RSpec.

Why RSpec? RSpec is a Ruby testing framework that strongly encourages human-readable tests. First time reading RSpec syntaxies, I must admit that I like it. RSpec syntax is really human-readable, thus very easy to read. Moreover, the syntax is pretty similar to Chai, a testing framework for NodeJS that I have used before.

RSpec has some “specs” that used in different part of MVC (Model-View-Controller) structure. These specs are:

  • Model specs to test models, will be useful for testing database behaviour
  • Controller specs can be used to test behaviour of specific method in a controller
  • Request specs to specify http request to the application and evaluate its response in black box approach
  • Feature specs, test by simulating a browser. I have not tried it yet but it looks pretty cool
  • Mailer specs, test rails mailer
  • View specs, see behaviour of rendered rails view templates
  • Routing specs, test routing, such as mapping between routes and controller actions, redirection from one action to another, and public & private routes
  • Helper specs, test helpers, handy small functions that may useful throughout the application

I think RSpec with all of its “specs” can be used in different scenarios when developing rails applications. Combine RSpec “specs” with its easy to read syntaxies, it for sure is one of the best testing framework for Ruby (on Rails) out there.

“If you’re not doing test-driven development, you’re doing debug-later development.” ~ James Grenning


Research done. Next thing to do is implement test scripts and integrate it to continous integration (gitlab-runner) to make seamless automated testing. I believe we will make strong tests, and make bugs pay for it.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s