February 6, 2013
September 14, 2011
Why do I need tests in my software project? Keep bugs away? Yes! Keep quality high? Maybe. Can you define quality?
I see that people often justify the demand for a high test coverage with their desire to have quality in software projects, however they’re only seeing a part of the quality, the bugs visible to the customer. Quality, that word alone, can be very subjective, meaning different things to different people. Of course, having a bug free software means a high quality software, but if I have a bug free software and cannot add new features or improve existing ones, is this software a high quality software?
Now that we’re all doing “agile development” (right? at least you may think you’re doing, because you have daily meetings, review, sprints, etc), everyone should bear in mind one of the critical purposes of tests.
Big up-front designs do not work anymore, never worked for that matter (you soon loose integrity between the code and the design in the papers). We’re no able to make decisions based on the unknown (though some people may think they can), so we leave every decision to the last possible moment, until we have all, or most, information needed to make a reasonable decision.
One fundamental aspect of agile development is that you evolve your system as you go, you do it in iterations and every iteration is focusing only on what is needed to deliver the features you committed for that iteration. Your system will evolve, iteration after iteration.
With this evolution of your system, you will also evolve your architecture and design. You will not add database support on the first iteration if you don’t need a database, right? It’s waste. Right? So, from iteration to iteration your architecture and design will evolve, based on the features you have to develop and those you have developed. This is what evolutionary architecture and deign looks like, according to Martin Fowler.
But, how do you evolve your design and architecture? One of the key practices to do that is refactoring. Refactoring, again using Fowler’s knowledge, is “the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the changes of introducing bugs.”
Refactoring is one of the key practice of any project using any kind of agile development methodology, backed by testing and continuous integration. There is no way you can refactor your code if you do not have a safety net, i.e., if you don’t have something that keep you away from breaking existing functionality. This is a key point of tests, to allow you to evolve your system design and architecture.. Of course these test must be automated, needless to say that.
January 30, 2011
Some people like it, others don’t. I like it, it’s so cool to make generic code, but as I ‘ve been experimenting with GTW to know it’s capabilities I found that GWT does not support Reflection. It uses instead a mechanism called Deffered Binding to overcome the lack of reflection.
When doing some kind of framework code with GWT, soon you’ll realize that you need reflection, as I did. Bad luck, you’ll have to dig into the underground features of GWT, namely deferred bindings and generators. You can learn the theoretical traits of Deferred Bindings in the documentation: http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsDeferred.html
Let me explain my scenario.
October 16, 2010
Isn’t annoying when you open a web page with a form and then have to click on the first input to start entering our data?