Hello dear reader. As I was staring at my computer and was trying to find a good subject for today’s blogs a bell ringed in my mind: APIs.
I never came across the name API until I started my job. I remember when everyone used to say ‘The API is not working’, ‘We need to call the API to make this process happened’ etc. and I was super confused so I entered google and wrote what is API. Google told me ‘Application Programming Interface’ more fancy words. I started to watch videos about it and also, we started to use them at school. Now I am the one using the term API.

Application – think of an application like credit card. You expect the credit card to help you purchase items and goods.

Programming – API allow the credit card needs to contact your bank and make sure you haven’t extended the limit in your card and is okay to go on.

Interface – is the way we interact with an application.

Simple for you: API define rules that developers must follow to interact with a programming language, software library, web interface or any other software tool. Everyone uses an API every day in some way. A simple comparable example would be you accessing a webpage in your browser. You make a request by entering the webpage URL and the view you see after you press Enter is the response. The API has the same process of request/response but the difference is that API requests provide data in their response.

But why do we even use API? Many of the APIs are made with the intention to allow 3^rd party developers to build applications using company data, Since the APIs simply provide data, there are limits on how a company can then go on to use that data. APIs act just like a door and keys. Only the people having the key can open the door and enter the room.

https://www.youtube.com/watch?v=InoAIgBZIEA This video is a great example on how to use the API ( how to call and get the information you need).

Hello dear readers. Now it is time to talk about Test Driven Deployment testing.Test driven development is a software development process that consist on the repetition of a very short development cycle. At first the developer writes an automated test case that defines an improvement or new function. After that, it produces the minimum amount of code to pass that test, and at the end refactors the new code to acceptable standards.

For test driven development the following steps are followed: 1. Add a test; 2. Run all tests and see if the new one fails; 3. Write some code; 4. Run tests; 5. Refactor code; 6. Repeat.

Test driven development is like a way to turn the code into an instruction manual. The goal of software tests is usually to catch any errors before making that software available. The first tests you write, are just like a roadmap for what the perfect version of the code is supposed to do. As this type of testing consist on the test written before the code for the program is written, you expect the tests to fail at first. It takes something that can be discouraging and turns it into a clear instruction for what to add next to the program.

Some of the benefits of TDD are efficiency, readability, etc. TDD just makes you a better programmer. It is said that most of the programmers don’t read the written documentation for a system, instead they prefer to work with the code. When trying to understand a class or operation most programmers will first look for sample code that already works with it.  Well-written unit tests do exactly the same and as a result unit tests effectively become a good portion of your technical documentation.
Let’s assume you add some new functional code, compile, and test it.  Chances are high that your tests will be broken by defects that are in the new code you just created. It is much easier to find, and then fix, those defects if you’ve written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps. I generally prefer to add a few new lines of functional code, typically less than ten, before I recompile and rerun my tests.

Please check out the following website for more info: https://medium.freecodecamp.org/test-driven-development-what-it-is-and-what-it-is-not-41fa6bca02a2. I found this website very useful in understanding TDD.