Nacho’s Blog - Grand Opening
Hi everyone! I’m Ignacio, and I’m the “new guy” here (Yeap, I’m a trainee!). So let me introduce myself: I’m a 20 year-old university student. I’m studying at the UAI (Universidad Abierta Interamericana) and I’ve just finished the first semester of 3rd year, which means that at the end of the next semester I’ll be a system analyst! J
For those who are wondering (and for those who aren’t too! LOL! xD!), I’m the long-haired stranger (”el extraño de pelo largo”, as the “Enanitos Verde”s would say) on the floor.
I have no previous experience in software development besides from what I’ve done for the university and some freelance web projects. This point is what I want to emphasize: I want to gain all the experience and knowledge as possible, in order to develop myself as a complete professional.
Test-Driven Development: The other way around
Well, this is the “grand” opening of my blog: TDD (Test-Driven Development).
I’ve read about this in the Wikipedia to have a general concept of what it really is and then focused on the subject with the book Test-Driven Development in Microsoft .NET. What I tried to do with the title was concentrate the main concept in a single phrase. Why that one? Because I realized that that’s what TDD is all about! It’s the other way around, like an inverse of the conventional development approaches.
Normally, you start testing the code at late stages of each iteration, once the coding is practically done (for that iteration, of course). Here, tests are made based on the code (to test that it works ok), so they are not made until the code is “ready to be tested”.
Regarding TDD, you start making the test before the code is done. In fact, code is made based on tests it is supposed to pass (or fail). Here, testing is not “at the end”; not only do they verify code’s functionality, but also guide the programming of the code itself. So: The code is done from tests, not tests from code. Testing helps the code meet the requirements in what it should do in case of correct function and failure too. It also helps finding defects in early stages of the iteration (when they can be managed quickly and with low cost). In my opinion, this is a great way to accomplish an engineering precept: “satisfy the requirements no less and no more“.
Finally, this was my conclusion of the subject. I hope it gives you an overview on TDD. Nevertheless, I’ve attached a file to this topic for more info on this: it’s a document that you can use together with the book I’ve mentioned earlier (it includes some theoretical concepts I could extract from each chapter).
Link for Wikipedia’s article on TDD: Test-Driven Development.