In this weeks journal post I will discuss the progress I have made implementing Test Driven Development into my App Jam project (Timeline) and reflect on some of the challenges and obstacles I overcame.
During Week Six I read Cowboy: An Agile Programming Methodology for a Solo Programmer, an academic paper by Ashby Brooks Hollar, which discussed Test Driven Development (TDD) being a useful tool for a solo developer, such as myself. The idea is that each new “feature” begins with a test. Clear user stories are used to cover the requirements and exception conditions for the test and then code is written to eventually pass the test. The importance in TDD is that tests are written before the code, which make the developer focus on the requirements, before the code. The practise promotes safer, tidier and less bug ridden code which allows the developer to be more confident with what they have written. From my experience reading blog posts and twitter feeds of developers throughout the industry within macOS/iOS and Web Development, TDD is a strongly recommended practise and as such set myself the SMART goal in Week Six to up skill in TDD.
In the testing world, code is tested by using assertions e.g. When a user posts a request to ‘/courses’ and they are not an authorised user, assert that they are redirected to ‘/login’. The assertion would return true or false. Does the user get redirect to ‘/login’? If not, the assert returns false and the test fails.
This week I have been going over the code I had previously written for my App Jam and writing tests for as much as I can. In hindsight I should have began with the tests but at that point in time, I didn’t know how to write them. Most of the assertions I have been writing are checking that the user is routed correctly, that the data is validated, and the correct data is presented to the user.
- WithFaker (line 11) - Includes the use of the Faker library into this class. Faker is a wicked library that quickly generates fake data such as names, addresses or text.
- RefreshDatabase (line 11) - Every time we run these tests a course is created and inserted into this database. Without this my database would quickly fill up with lots of test entities, so the RefreshDatabase puts the database back to what it was before running the test.
- $this->withoutExceptionHandling() (line 16) - Laravel handles quite a few errors elegantly automatically. But in test cases you typically want to see those errors, so this stops Laravel from doing the exception handling.
- assertRedirect (line 23) - Assert that the user gets redirected to ‘/courses’
- assertDatabaseHas (line25) - Assert that the database has the attributes that were just used to create a course in the database.
- assertSee (line 27) - Assert that the view shows the title of the course that was just made.
Running the Tests
From the Terminal From Atom, using a community package atom-phpunit and keyboard shortcuts (Alt-Shift-C) to streamline the process of testing a class.
The tests that run on your code are only as good as they are written. I find tests and this process to be incredibly useful to provide me with the confidence that code has been written correctly but also to provide a thorough grasp of the requirements of a “feature”. You can’t write a good test without ascertaining all requirements and implementing all assertions within the test.
- Specific - Implement user authentication via email into the App Jam project writing tests first before writing any code.
- Measurable - An email should be sent to the users email address upon registering which provides a unique link to the server authenticating the user receiving the email as real.
- Attainable - Watch Laracasts’ Mailables episode to remind yourself how to send email.
- Relevant - Put TDD in to practise by writing the test first and then code after.
- Time-Based - Implement this within the next sprint and complete by Sunday 7th April.