Repository files navigation

updated 21 April 2022

I was too intimidated by the conceptof code testing. Whywill you test your code in the first place? Doyou not trust your own code? Will itnot work as intended?

But then by reading so much about this, I fullygot the hang of it. So here it goes:

Without the automated code testing,the tendency is to testyour code by running the entire program andmanually testing it. So, you are still testingit without being aware of it.

For example, for students doing programmingin Robotics, since their focus is just to knowwhether their code is actually working,they will be manually running the codefrom time to time. If the code did notwork as intended, then they will tracethe problem. This entire processis being repeated and is actually timeconsuming particularly when the codeis getting longer and longer. And takenote, it is not yet one big project.But testing is already there, they arejust doing it manually.

As was mentioned from my example,if you don't have any idea aboutcode testing, well I say,you are doing itwithout being aware of it.The tendency is torun the whole program and manuallytest whether each part of thecode is working as intended.

Now, this is only practical if yourproject is just a small one. Butsoftware development nowadaysis already a very sophisticated one.So, testing it manually will surelybe a headache. Plus, itis not that efficient.And even a well-tested code will notalways work as intended to be.Our role is just to minimize errors andmaintain the code.

Others are really confused about these twothings, are you testing while you are debugging?Or conversely, are you debugging while you aretesting?

Debugging was a popular practice beforethe termcode testing was coined. And yes,developers back then manually testtheir code. And theywere referring to testing as part ofdebugging, without, of course, the knowledgeof it. But there came a time,it was recognized as a separate process.And of course, software developmenthas been continuously evolving, testingnow is a very sophisticated one: thereare technologies just for testing alone.

So testing now becomes the way to actuallylook for system errors and debugging isthe process of solving these errors.Hence, debuggingis a manual task to be done by a talenteddebugger or the developer himself whiletesting, the act of finding errors, ismostly automated through coding.By making testingan automated one, you save time and effort,since you don't need to run the entireprogram just to see whether your codeis working as it is intended to be.

Unit tests and integration tests are the mostcommon tests that are being referred tomainly because these two tests should be done(most of the time) bythe developer himself.

There are on-going debates as towhat is considered a unit, say,it can be a component of a programand whether you test first beforeyou code and whether every lineof code should be tested.Of course, development is upto the programmer or the companyin what they believe is thebest for them.

Integration tests, on the otherhand, are tests when you arecombining several components:will they still work as intended?Problems arise when thereis too much dependence ina program. So mainly, eventesting is just in your mind,it will affect the way youuse global variables andcomponents that are dependenton one another.

For me, personally, I writeunit tests and integrationtests for my projects.

In my experience,I had developed the projectsfirst without any idea aboutcode testing.So I wrote them backwards.With that, I refactoredeverything in such a way that:

1. a function willreturn just one value
2. components should notbe dependent on any otherpart of the program, ifthe developer can avoidit
3. return values shouldbe handled by argumentsand should be returnedproperly (remember, ruleno. 2)
4. global variables shouldbe used minimally andshould be closely monitored
5. throwing exceptionsshould be closely monitoredthrough testing becausethrowing exceptions are actuallytricky

Then, the effect was immediatethe very first time I did this:when I looked at the code, it wasreally neat.

So, from that point in time,I realized I need toinclude code testing in myworkflow. But I just write unittests for components or functions thatI feel I really need to focus on.

This only means that a developershould not find it difficult towrite unit and integration tests,if he/she finds it difficult,the source code is really notthat neat.

But others will still insist, they aregood and excellent coders and verycareful writing quality code. Isay I had the same feeling buteven if you just started thinkingwhether your code is testable,you will have a different approach.You will see things in a differentperspective.It's just like you looking at yourwork just like other persons in chargeof checking your code. Remember thatothers see errors better thanourselves.

Other tests just like black boxtesting will be done by another person,usually a tester. This is anotherlayer of testing for quality assurance.Don't you know that bugs can causemillion dollars to be just wasted?So, a company really needs this kindof quality assurance.

You can check out my actual codes withunit and integration tests:

https://github.com/jdevstatic/java

Here are the detailed tutorials for this code testing:

https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

https://www.zeolearn.com/magazine/what-is-code-testing-and-why-is-it-important

https://www3.ntu.edu.sg/home/ehchua/programming/java/JavaUnitTesting.html

https://www.geeksforgeeks.org/differences-between-black-box-testing-vs-white-box-testing/#:~:text=Black%20Box%20Testing%20is%20a,is%20known%20to%20the%20tester.

https://www.geeksforgeeks.org/differences-between-testing-and-debugging/#:~:text=Testing%20is%20the%20process%20to,the%20failure%20of%20implemented%20code.&text=Debugging%20is%20done%20by%20either%20programmer%20or%20developer.