Unit testing #12
3 participants
I don't know if you already learned about this on your own but here's my $0.05:
Unit testing as I understand it is part of a development philosophy called Test-Driven Development (TDD). In TDD, you write a test for a feature that you plan to implement FIRST before you write the feature itself. The test fails (because the feature is not there yet). Then you write the minimal amount of code to make the test pass. You keep writing tests and writing code, making sure all previous tests keep passing.
For example, a feature request currently exists on the site called "allow image upload from URL."
1. You would first write a Selenium test that would look for an "upload from URL" button or something like that. It wouldn't find the button, so it would fail. You would then create the button and the test would pass.
2. You would then write a test where Selenium enters an image a URL and tries to upload it. It would fail, then you would add the upload-through-URL feature, and it would pass.
3. Then you would enhance the UI look of the button and run the tests again. Now they fail, what happened? Turns out you forgot to close a <div> tag and now the whole UI is out of whack. Unit tests help you make sure new additions don't break anything in an automated way.
I want to learn more about the Laravel framework and contribute, but there's never enough time. :(
That's a really good synopsis, thank-you for taking the time to write it out.
I've been putting this off since day one, but I'm writing out a feature for administrative config now. I'll see if I can add some unit tests for that. I think Laravel has a built-in way of doing unit tests, so this is a good excuse to try it out.
Unit testing is difficult to get into, but is very rewarding! If you're interested in a book on unit testing, I can recommend "Extreme Programming" by Kent Beck. That book was what inspired me to really commit and start writing the tests for everything.
I did Test Driven Development recently, for my Software Engineering class, and I definitely recommend it.
Adding to what @panasenco said, TDD was very rewarding when we needed to refactor code. Changing lots of code can be scary, but not so much when you have lots of tests to help you debugging and understanding whether the new code is working 100% or not 
It also helps you understand the quality of your program based, as you can simply check the percentage of tests that pass and fail. However, that implies the tests are good and thorough. They can be seen as requisites of your program - if you want your program to do X, test the X functionality and make sure it passes.
@panasenco If you'd like to look at commits 21a3333 and b413875, this is my attempt at doing unit tests. I'd like input before going out into other unit tests.
............
Time: 2.12 seconds, Memory: 26.75Mb
OK (12 tests, 45 assertions)
@jaw-sh These look great to me! I like that you wanted to make sure the response codes were correct before doing anything else. The next step would be to add extra tests that test functionality (is this element on the page that the user is navigated to?). Awesome start IMO!
@panasenco That's a good idea. Interestingly, this already helped me resolve a bug. Board logs had become broken with recent changes because they referenced a template which requires data the controller doesn't supply. When I saw a 500 error for that assertion it made me laugh.
This whole thing is brilliant. At my old job, which had hundreds of views and zero unit tests, it was a continuous game of whack-a-mole because new features would break old ones and we'd not notice until a client complained.
I don't know what Unit Tests are but they sound really great.
Be sure to write #1 Proper Documentation on them, too.
Laravel Doc: http://laravel.com/docs/5.0/testing