Learning about Test-Driven Development

So for this week, I have decided to read “What is Test-Driven Development?” from the Rainforest blog. The reason I have chosen this blog is because from what I understand of test-driven development, it is hard to apply in practice and requires a lot of time when doing this process, the first time. This will help me in understanding the advantages and disadvantages of using this process.

For this blog post, it goes over what the benefits of test-driven development are, who needs the development in question, how does it work, and the disadvantages of using it. Test-driven development is a software process that follows a short, repetitive, and continuous cycle of creating unique cases for companies want in their applications. Unlike traditional software testing, test-driven development implements testing before and during development. The benefits provided in this process are quickly sending quality code in production, efficiency building coverage on the building’s application, and reducing resources required for testing. This development is good for teams for fast release cycles but still want to ensure their customers are receiving quality results and teams with little practice in-house QA practices instilled but still value quality. The disadvantages are product and development teams must be in lock step, difficulty maintaining transparency about changes, and initially time sensitive.

What I think is interesting about this content is it does give scenarios for each part to express the process and why companies would use this development. From the blog, it breaks down to the meaning of the titles, giving the details of the scenarios, and finally the charts to give the idea of the process when working together. The content has changed my way of thinking in understanding the process and not believe that it is very difficult in introducing this process to a person that is learning programming the first time.

Based on the content of this blog, I would say this is straightforward to understand once going over the fundamentals a few times. I do not disagree with this content given by this blog because it helped me understand the idea of test-driven development with the short descriptions and charts that show it. For future practice, I shall try to refer this process when teaching those who have difficulty with programming.

Link to the blog: https://www.rainforestqa.com/blog/2018-08-29-test-driven-development/

 

Advertisements

The two ways of testing

So for this week, I have decided to read about “Pros and Cons of Dynamic Testing and Static Testing” from the testbytes blog. The reason I have chosen to read this blog is because I only have heard bits of both testing methods and I want to understand the advantages behind them. This will help me in seeing how they work and be able to use them in an expected way.

This blog post basically goes over as the title says the differences between static and dynamic testing. Both have their own purposes in making sure the software runs functionally. The blog post provides the techniques used and what are the benefits overall in both testing.  Static testing is an early stage of development and can be done manually or with a set of tools. It is useful in seeing the code flaws and giving documents to review the overall software. Another name for this test is verification testing.  With dynamic testing, the code is used to check how well it will perform in a run-time environment. It is to ensure that the end product is designed with the requirements given by the business clients. Another name for this test is execution testing. This one can be used in any levels of development. With both of these methods by their meanings, development companies can use them in to design flawless products in concept.

What I think is useful about this content is the way the ordering goes. From the blog, the definition is explained first to get the basic idea of the testing, then the techniques mentioned get broken down, and finally the pros and cons. The content has changed my way of thinking in how both the testing works. When I first heard about both the testing, I was briefly told that both can be used to find the errors and review coding in the software. However, one can be used faster while the other can be used around the end so that the product can be all set for the client. This was a misinterpretation in quite a time for me before finding the blog.

Based on the content of this blog, I would say this is informal and easy to understand when following along the order of it. I do not disagree with this content given by this blog because it helped me understand the ideas of the testing methods even without needing to see it in action. For future practice, I shall try to refer both testing advantages as reference for software testing.

 

Link to the blog: https://www.testbytes.net/blog/dynamic-testing-and-static-testing/

Understanding Inversion of Control

So for this week I have decided to read “Inversion of Control- An Introduction with Examples in .NET” from the joelabrahamsson website. The reason I chose this article is because with the subject of automatic testing, Inversion of Control and Dependency Injection is what I do not get mostly. It is usually a topic that I do not hear that much, so I believe this will help in understanding on the purpose of using both principles.

This article basically by the title goes over Inversion of Control from the definition to the ways of using it. So Inversion of Control is essentially a way to the invert the flow of control in comparison to procedural programming. It means that every module can focus on what is it designed for and ensures clarity with little complications. The benefits in using Inversion of Control is that when changing the interface of a particular class uses in runtime, that class can no longer be dependent on another class and the code can be decoupled. This means that the class is provided the ability to swap dependency implementations in different environments and allows a component be tested through mocking of dependencies. When having to apply Inversion of Control and getting the instance, there are two ways to get it without having to know about any concrete implementations. These ways are Dependency Injection and Service Locator. Dependency Injection injects an instance by using construction injection or property injection while Service Locator injects an instance based on the configurations of the concrete class. Dependency Injection is mostly used than that of Service Locator, but Service Locator can be used when there are situations Dependency Injection seems impractical.

Based on the content of this article, I would say that it was a good overview about the ideas of Inversion of Control. The author was able to give a few examples of using it and have the UML diagrams to back up with the codes provided. What I did before to understand Inversion of Control was to envision real life scenarios to compare without and with it. The concept is that without it, there is limited options for a software consumer. But by implementing Inversion of Control, there are more options over the software. With that in mind, it made envisioning scenarios easier than it seems.

What I learned from this article is that Inversion of Control shall not be used in all cases because of program flow. The idea is that while it is a useful way to design methods when writing a library that will be reused, it is only critical if there are many cross-cutting concerns. For future practice, I shall try to use Inversion of Control when it is necessary to change a small part of code. This is because it is a practical way of reducing code duplication and it is strong for coding against interfaces instead of implementations.

 

Link to the article: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

 

The Different types of UML diagrams

For this week with my spare time, I have decided to read “Process Modeling (UML Diagrams)” from the mohamedelgendy blog. The reason I have decided to read this one is because it is crucial to understand the benefits of each UML diagram. It will help in understanding modeling and the cases from it.

This blog post goes over eight types of UML diagrams and how each diagram is used for modeling. So basically, UML is a set of standardized (Unified) diagrams that offers different views of the same system from construction (front elevation, electrical diagram, floor plan, etc.). The first and simplest one is the class diagram and it describes the structure of a system by showing the system’s classes, their attributes and the relationships among these classes. It is also a static structure which shows what interacts but not what happens when the classes interact. Second and third one is the component and deployment diagrams. Both diagrams in many cases are combined into one as component diagrams depict how the various components of a system and show the dependencies among them and then deployment diagrams show how they interact. For package diagram, it can be used to obtain an overview of a large system and the choose to display the individual classes inside the packages. Next is the state diagram which describes the behavior of a system where it shows all the possible states an object can get into. The sixth one, object diagram, is a static snapshot of a dynamic view that depicts a complete or partial view of the system at a specific time. For sequence diagram, it displays the sequence of events between entities of the system to show the dynamic view of the system. Finally, for the activity diagram, it is used to describe the sequencing of activities, actions, choices and system’s logic and will help with complexity.

Based on the contents of this blog, I would say that it was worth to read about. The author was on point with giving introductions to what is an UML diagram, definitions that are basic and good reminders to each diagram, and showing the implications when it is essential to know. What I try to understand the UML diagrams before is using the diagrams I do know such as flow charts. Using the diagrams, I would try to solve construction problems for example from the logic of it.

What I learned from this blog of UML diagrams is that while each of the diagrams has its uses, only use one style for something specific. The idea I got from this blog is that developers should try to find the right UML diagram that is essential to the design and not cause confusion from it.  For future practice, I should try to use the sequence diagram a lot more than the other seven diagrams because it benefits in organization for the overall structure and has a flow that is easy to understand.

Link to the blog: http://mohamedelgendy.com/blog/business-analysis/business-process-modeling.html

3 Principles that makes a developer’s life easier

So for this week, I have decided to read another blog and that is “3 Principles to simplify your life as a developer” from the iTexico Blog. The reason I have chosen to read this blog is because I usually do not get a clear grasp of these kinds of principles. With getting a clear understanding of these principles, they will help in applying code, simplicity, and managing the overall process.

As the title applies, this blog post basically goes over 3 principles that are basic but powerful that will make life as developers easier and they are KISS, YAGNI, and DRY. The first principle KISS stands for Keep It Simple, Stupid and the meaning of it is straightforward. The simpler the code is, the simpler it will be easier to maintain in the future. This means that according to the author’s advice, developers should avoid using fancy features from the programming language they are having it in on. It does not mean developers should not use these features, it is to say only use them when there are perceptible benefits to solving a problem. Second principle YAGNI stands for You Aren’t Gonna Need It and the meaning is rather related to programming the first time. We do not want to waste time coding extra features that might not fit to what is needed or in the worst-case scenario, it will not be used. So from the author’s advice, when there is an unexplained anxiety to code extra features, take a deep breath and see the pending work at the moment. The third principle DRY stands Don’t Repeat Yourself and the meaning is clear to understand. We must try to maintain the behavior of a functionality of the system in a single piece of code. This means to keep it in a steady pace to avoid redundancy.

Based on the contents of this blog, like the concept of KISS, I would say this was simple and easy to read. The author gave the meaning of the principle, explained the origin of it, and advice on how to apply it while programming. What I did before to try to understand these principles while coding is that I try my best to not write down a method twice or an extra class unless needed.

What I learned from this blog about the principles is that DRY should be not used all the time in the life as a developer. The idea I got from this blog is that while DRY is a good principle to follow, it will sometimes when violated lead to a solution which is called WET or Write Everything Twice and that is a bit of time spent. For future practice, I should try to apply the KISS and YAGNI principles a bit more while writing down code as it will not only save from being overwhelmed on how the code works but also others that can benefit from it.

Link to the blog: http://www.itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life

Approaching Complex Code

So for this week, I have decided to read “Code Smells: Too Many Problems” from the Jet Brains and Intellij Idea blog. The reason I have chosen this blog is because while I have my experience of parsing codes, I do need another way to approach complexity. It will help in figuring out the simplest step to take first when there is complexity in coding and not be overwhelmed by it.

This blog post basically goes over three approaches that is figuring out how to tackle complex code. Each of the approaches have their pros and cons. The first approach is simple but effective to do and that is break down the method into smaller sessions. While it might help for methods with multi responsibilities, it does not make some other smells more approachable to work with. However, it also does help in determining when is the right time to refactor.  Second approach is to work on one smell at a time. It is a variety of steps that the author has showed to get this point for the series of code smells. This is the less risky and easier to reason approach that gives simpler code. The third approach is to step back and try to model the problem. Instead of looking at individual smells or individual lines of code, this approach introduces new domain objects to model what is happening in the code. It encourages a bit of redesign and may lead to new classes that can help with other areas of code, but be aware that it will have the same problems as the other two approaches if not used carefully.

Based on the contents of this blog, I would say this was a pleasant read on getting started in tackling complex code. The author was able to show how the approaches work with a sample code and addressed the drawbacks from it. It was easy to understand and has the What I did to getting started is to write down one method at a time and try to refactor it based on the design it has been used on. Sometimes I would try to write down comments if I do need to have a clear reminder of what I’m trying to do while refactoring.

What I learned from this blog is that if breaking down the methods and refactoring happens to lead to an inconvenient end, then perhaps undoing a few steps back is not a bad idea. The idea I have gotten from this blog is that all the tests should pass, and commits should be small, but very frequent. This helps in making sure that it is easy to stay back and not having to be in a place that can lead to a complete halt. For future practice, I shall try to use the rule of three that will help in determining if a method is needed to be broken down into smaller pieces.

Link to the blog: https://blog.jetbrains.com/idea/2017/09/code-smells-too-many-problems/