Showing posts with label testing. Show all posts
Showing posts with label testing. Show all posts

2014-04-11

Real life stories behind bug reports

I've found some gem, while browsing through Android reported issues:

My Nexus 10 was on silent mode this yesterday at church. I was using the YouVersion Bible app, taking notes. All of a sudden my Nexus 10 let off a shreaking siren type noise that couldn't be silenced. My church (of about 1500 people) all heard it, it stopped the pastor mid-sentence - as I ran out of the auditorium. Has anyone else experienced something like this? I don't think I can ever trust it to be quiet - in a quiet place again.

source: Aaron.Ky report at https://code.google.com/p/android/issues/detail?id=42447

It shows also why some environments have distance to newest technology. 

2013-08-10

99 $items on the $container ...

Do you know the song that goes like:

99 little bugs in the code
99 little bugs in the code
Take one down, patch it around
~
117 little bugs in the code
...

That was about some funny facts we are experiencing some days.

Now something more didactic:
http://www.99-bottles-of-beer.net/


2008-10-27

Polishing PHP application - Role of tests

Real life scenario:
Slightly changed requirements from category "eventually" - gives as result quite lot code changes.
An extra problem was that in one production environment it have to work on PHP 4, so application needs downgrading from PHP 5 mainly in XML processing area.

Solution:
Writing more tests for new features.
Gradually code fixing and refactoring.
As a result I have more clean, better working code with new features and potentially new undetected bugs :) .

Savings from using unit and regression testing are almost priceless.

Trying to do some changes like that in PHP production code without automated tests will be really painfull.

2007-11-12

Weakly typed languages need more testing

I have to written and managed some projects using scripting languages. Those languages often have no strong typing or have duck typing like in python. This is their strength on one way, and weakness on another because it's easier to break the code giving mistaken parameter. Most of this errors are visible after running a buggy code.

Some of older programming languages have built coarse in error messages like in PHP or old ASP family. It doesn't help during debugging and can be really frustrating indeed.

Automatic testing is good, everybody can say even if they don't use it. So it's best to use unit testing specially for that kind of code. In that way simple errors caused by non checked and mistaken parameters can be easy found and unit functionality is checked also.

So once again I say- automatic tests are good. Scripting languages like python, perl or php need automatic tests as additional "safety net". Comparing code written in weakly and strong typed language both covered with tests both may have equal quality, so there is no real typed language quality advance over non typed one.Good tests are what gives you quality and confidence.

So next time if you are going to code something think about- how to test it.