Back when I did corporate IT contracting, software testing was done after-the-fact in the "waterfall" style.
First you gathered requirements, then you programmed, then on to the next phase. There were two types of Acceptance Testing: internal, and user. Internal = the business analyst blesses the software for the project manager. User = the department head signing off that the software works therefore their cost centre gets dinged for the project --> good luck with that!
Testing was always something that was done after the fact.
Rapid Application Development, in my experience, ended up being iterative waterfall, solving none of the problems it was supposed to solve. The promise of delivering more for less, faster, was "bravo sierra". Testing was still done after-the-fact.
The stunning thing about testing these days is that it is done first. Perhaps more than moving from procedural code to object oriented code, doing testing first is tough culture shock.
But I am all-in with it, with one caveat: I'm ramping into it as a longer term skill. I am not halting my LaSalle Software coding until I learn "Testing First" because there are a dozen other critical software skills that I need to learn (front-end JS frameworks, for one; and, creating retina-ready images which is becoming a surprisingly not-as-straight-forward-as-I-want side project), client stuff, and my kids expect Daddy's special macaroni on Tuesdays. Oh, and I am on a roll developing L5 based lines-of-businesses (yes, plural) and am actually on track to bring 'em all into fruition this year.
So I decided that I would take a little piece of my app development, and "do unit tests". Then, just to see how it works, I'd "Travis-ci" 'em, to see how it works during "git push". My reaction could be summed up in one four letter word: S-O-L-D.
You mean that every time I push code, these tests are gonna run -- and if for some reason there's a problem, I will be told? Well, why wait until I push code? Run 'em locally!
A benefit of PHPUnit was closing my browser. I can run my app from the command line with PHPUnit. It is a subtle thing, but I noticed that I run PHPUnit from the command line all the time, more often than I use to the browser.
The one thing I just couldn't quite nail was running my forms "just like a user would". I figured that I need Selenium (http://www.seleniumhq.org) for that, but put off setting it up. Just another one of the endless things to learn and set-up, and meanwhile I had not nailed down L5's new command/event handling yet are fundamental to my apps. When I realized that L5 came with integration testing with PHPUnit (http://laravel.com/docs/5.0/testing#framework-assertions), I dove in -- but got stuck at the "where's your token?" problem.
Ok, so I still do not "test first". However, my mentality is changing, despite never touching Behat, Codeception, etc. I am doing something I've never done before, which is a critical antecedent to "test first": I am making my code testable.
Making my code testable is forcing me to do theoretical things: small methods, one class for one thing, return things that are measurable, etc. Funny enough, but I write less IF statements, and almost never write CASE statements because my IF statements do not nest. What I am doing now that is different, and actually infuriated me initially, is I write about a zillion more methods. And these methods are tiny. Why? To make my code "assert-able".
The problem is that my individual methods are assert-able, but I need to know if these individual methods "work as a team". Before, in my corporate IT experience, "integration" was organizational, not technical. It meant getting the DBA's, programmers, and users in one room to get sign off (ha!). Now, "integration" is technical, and it can be automated!
I've only begun my journey, but I've begun. I read the books, seen the videos, but without hitting the issues squarely with my own programming, I'd not have grasped a darned thing about what I read and saw.
I foresee the day that I use testing tools to speed up my development. If only we had these tools back in the day, eh! It would have driven my managers and user departments crazy because they would have had to get better technically but that's another story... Originally, I thought "first red, then green" was "bravo sierra". Jeffrey writes in his "Laravel Testing Decoded" that you "slime your way into green" (excuse my paraphrasing), which I thought was hilarious and utter nonesense.
Joke is on me, now, as soon I'll be sliming away. When it comes to testing, I am still crawling, but at least I am on the move. My code has improved big time already, and the theory being touted is taking shape in practical form like never before. I'm not quite at the "red first, then green" (at least not by design!), but I am ramping into a TDD mentality.
My counsel to you: Go For It!
