TDD Kent Beck

The Test Driven Development is something i have never done and I’m not used to, to be honest i had to take some time to fully grasp the idea because i found confusing the thought of generating test for a code that hasn’t even been written.

I feel like it make take some time to get used to this workflow because code has to be deleted often if you make mistakes (which i do very often) so it means changing everything. On the other hand it sounds like a great advantage to have in your master branch only code that has been tested and worked, it makes things more stable.

The technique  sounds amazing, basically you just need to have all tests in green, and if you have all of them green then the program as a whole is green because mistakes don’t propagate precisely because all your tests worked before…wow.

I think TDD is perfect for pacient people because you are developing small parts of the code at a time, taking care of it until it’s as good as it can be and then move on. For people that are not as pacient it must feel like a burden to do all this test in small parts instead of having and entire thing and then from there solve the problems.

In conclusion, only reading about it TDD sounds too tiresome for me but i will give it a chance to change my mind, i might get pleasently surprised. And i’ll keep in mind the most important: test && commit || revert

Lisp

The article, Lisp: good news, bad news, how to win big was written by Richard Gabriel and originally published in 1991.

Troughout the lecture I could grasp that at the time this was written, Lisp was very popular and used but then it got really bad reputation for many reasons like problems withing the language and also how people talked about it damaged its image a lot.

There were a lot of things done right with Lisp that may have inspired a lot of other languages to do the same like standarization, it had good performance, good integration to coexits with the different programing languages that existed, and of course you could do object oriented programming.

Then there were all those things that Lisp failed at, the most remarkable are:

• Simplicity — the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
• Correctness — the design must be correct in all observable aspects. Incorrectness is simply not allowed.
• Consistency — the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
• Completeness — the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

It had a different philosophy for this things that at the end of the day didn’t sit well with most. Other things it failed at were that, even thought it might have seem easy to build things with it, it was not that simple to make good programs, there were a lot ofmistakes people could make about the declarations, implementations and bad data structures.

This is a good article to reflect about how not a tool is all good or all bad, they have both its good things but also their bad side. We should look at this thing in our current tools and thrive to make everything better just like how other programming languages started to rise because they were better at more things. It is an iterative process, look at what we have and work on top of it to make it ideal for you.

https://gist.github.com/iantruslove/860aec352c8271e20827824ae6d1a0d0

(I don’t get this meme cause i’ve never used lisp before but if someone have they might find it funny so…)

OO and Agile

First let’s look at what is Agile. Agile are a group of methods for software development based on an iterative methodology, where requirements and solutions grow and change through collaboration between various teams. It is a way to promote disciplined project management.

http://codigodelsur.com/what-is-agile-software-development/

And what does Agile have to do with Object-Oriented? Well the thing is that the way to work with Agile  in the best way is using a model-driven approach, which is baically object oriented approach. Your arquitecture should be OO or it  will be a nightmare to work with Agile. Because of the constant changes in process due to Agile methodology, is ts much more managable in modules than with other types of programming.

There are 2 mainn points why OO way of thinking is vital for Agile:

First, they system should model the customer’s thinking. Having the clases be the code representations of real objects and the methods modeling the activities they do in real life and the way it all conects to each other it’s much more understandable for anyone outside the programming world.

The other issue is the consquences that object oriented programming has: the implementation of objects has to be opaque, your goal is to be able to change the whole implementation of the object without the customers knowing that something has changed. If the public interface doesn’t change then no other ones should notice that changes were done.

In other words, to be able to pull of the Agile methodology, you should be thinking in an object oriented approach.

 

References:

https://www.forbes.com/sites/stevedenning/2016/08/13/what-is-agile/#487232bf26e3

http://www.drdobbs.com/architecture-and-design/oo-as-a-prerequisite-to-agile/240164883

Test Driven Development

Test-Driven Development is a technique to develope software consisting  on a small lifecycle repeated for different test cases depending on what we want to do.

The “rules” that we need to follow when writting code while doing it with the TDD technique are:

• Write only enough of a unit test to fail
• Write only enough production code to make the failing unit test pass.

So it consist of the next cycle:

https://blog.usejournal.com/test-driven-development-understanding-the-business-better-9c4cae4cb990

Red Phase

In this phase you must not be thinking about the implementation, what you have to have in mind is writing a clean interface for future users. You write a test that makes use of a piece of code as if it was already implemented even though it is not. You can say that what you design here is how you think the code will be used by the clients.

Green Phase

This is the fun part: where you actually code 🙂

What is really important is that you are writting the code that will make it pass the test that was defined during the red phase, instead of programming  all the algorithms and implementation that you might think it’s needed. In your mind the only goal should be to pass the test, even if you don’t follow the good practices of coding.

Refactor Cycle

This is the phase in which you clean the code. You change your code to make it better looking at the same time that you keep the test passed, you can’t modify the code in a way that it won’t pass the defined test because that is the whole purpose of this cycle.

This kind of developement is not for everyone because it limits you while coding into only thinking about the use case, this may be really hard for some people so thats why they will rather use other techniques.

References:

https://medium.freecodecamp.org/test-driven-development-what-it-is-and-what-it-is-not-41fa6bca02a2

Testing in OO

https://me.me/i/stop-testing-me-i-said-pencils-down-o-o-dub-9776582

Testing an Object Oriented program is done differently than other programs, the testing is in three levels that are (1) unit testing, (2) subsystem testing and (3) system testing.

• Unit Testing

In unit testing, the individual classes are tested. It is seen whether the class attributes are implemented like it was designed and whether the methods and the interfaces have any errors.

• Subsystem testing

It involves testing the associations within the subsystem as well as the interaction of the subsystem with the outside. Subsystem tests can be used as regression tests for each newly released version of the subsystem. For subsystem testing we can use two types of tests: thread based testing (all classes of a use case are integrated and tested) and use based testing (the things are checked by hierarchy level, starting from individual classes and growing the test into bigger modules).

• System testing

It involves regression tests and some other different tecniques to test the system as a whole, we need to assure quality. System testing can be (1) Alpha testing, which is done by the people that develope the software, or (2) Beta testing, which is done by a group of selected customers.

There are different types of tests specific for object oriented programing called grey box testing, the most important ones are:

• State model based testing: This encompasses state coverage, state transition coverage, and state transition path coverage.
• Use case based testing: Each scenario in each use case is tested.
• Class diagram based testing: Each class, derived class, associations, and aggregations are tested.
• Sequence diagram based testing: The methods in the messages in the sequence diagrams are tested.

We need to do all this kinf of tests ultimately to assure the QUALYTY of the software, so it may seem exhausting but is necessary if we want to deliver a good product.

References:

https://es.slideshare.net/smartangel318/object-oriented-testin

https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_testing_quality_assurance.htm

Verification and Validation

First we need to define what is verification and validation:

Verification is a process of evaluating the intermediary work products of a software development lifecycle to check if we are in the right track of creating the final product.

Validation is the process of evaluating the final product to check whether the software meets the business needs. In simple words, the test execution which we do in our day to day life.

https://www.guru99.com/verification-v-s-validation-in-a-software-testing.html

You could say that verification answers the question ‘are we building the product right?’ and validation answers to ‘are we building the right product?’

When we run a verification test, the thing that we are looking for is that the software is being built according to the requirements and design specifications accorded before. On the other hand, a verification code is made to check if the product actually meets the clients needs by testing it on the real environment.

There are various standards like ISO / IEC 12207:2008, CMMI and IEEE 1012.

While we are on the software developement lifecycle, we can verificate and validate different things throughout each phase: (1) planning: Verification of contract, Evaluation of Concept document, Performing risk analysis. (2) requirement phase: Evaluation of software requirements, Evaluation/analysis of the interfaces, Generation of systems test plan, Generation of Acceptance test plan. (3) design phase: Evaluation of software design, Evaluation / Analysis of the Interfaces (UI), Generation of Integration test plan, Generation of the Component test plan, Generation of test design. (4) implementation phase: Evaluation of source code, Evaluation of documents, Generation of test cases, Generation of the test procedure, Execution of Components test cases. (5) test phase: Execution of systems test case, Execution of the acceptance test case, Updating traceability metrics, Risk analysis. (6) mantainnance phase: Evaluation of the anomalies,  Assessment of migration, Assessment of the retrial features, Assessment of the proposed change, Validating the production issues.

References:

https://www.softwaretestinghelp.com/what-is-verification-and-validation/

http://softwaretestingfundamentals.com/verification-vs-validation/

Code Revision

https://medium.com/palantir/code-review-best-practices-19e02780015f

Something you need to do to better the quality of your code is having someone else look at it so that they can have a non-biased look and be able to provide feedback to better the software.

When you review code you must ask the programmer the necessary questions for you to know what the code is meant to do: ask why does certain classes exist, what does the functions do, why are those attributes needed, ask  about the problemso so you can think about what would you have done to solve instead of what was done by the person who coded, if you can think of a shorter/cleaner solution question the programmer on why they did what they did instead of the other solutions.Be on the look for better abstractions, look for code chunks that may be repeated that could be put into one function.

Try to think about those use cases that the author may have not considered before and try to look for cases in which the program might fail.

Overall, check the legibility of the code, if it was easy to read and understand or if it is all messy and over the place.

Think about other tools that the author could have used to implement certain things of the code but didn´t use because they might not know those existed or because they decided to not for a specific reason.

Basically, what you need to do when you review code is QUESTION EVERYTHING.

References:

https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

View at Medium.com

View at Medium.com

Classes to code

We have invested all those time into making those diagrams but now how do we transform them into code?

Imagine we have our uml diagram that we want to make into java code:

http://lazysupply.co/uml-class-diagram-arraylist.html

We need to create those classes that we stated that we had, in this case we have 4 of them: Passenger, Train, TrainRide and Login. Each have their attibutes that we need to add to the class, plus the methods that we thought each of them should have. THen we alsoneed to consider the type of relationship each class have with one another, it could be a relation of composition or aggregation or some other type of relationship, all that we should correctly translate into the code, making a class an interface, the parent/son of another or just make it a normal class.

This is why we should thrive for better diagrams, if we make the perfect diagram then when we translate it, it will inevitably be good code because it has been well thought through, all the attributes are the right data type, they are all the necesary ones, the methods belong to the class that will hold them and also all the relationships in between the clases are the necesary ones to have comunication inside our program in the most logical and eficient way without compromising the independency of each component (that each class modifies its own attibutes and calls it’s own methods and not the other ones).

References:

http://lazysupply.co/uml-class-diagram-arraylist.html

Putting it all together

Finally, we are at the last chapter of the book.

This is what we’ve been waiting for, the moment we put all those pices together to make it all part of a single thing. For this we have had followed this developing process:

1. Make sure that your software does what the client wants: here we  do the feature list, use cases diagrams, break up the project and list the requirements.
2. Apply OOP principles to add flexibility: includes domain analysis, preliminary design, and everything to delimit the problem
3. Strive for mantainable and reusable design: this is when we implement the solution and we have to make sure we have an order and clear documentation for when we want to add features, update or whatever we need.

When we were thinking about the project i have to admit that sometimes we were to caught up in what we wanted the program to be that we didn’t stop and think what a customer might want/expect from something like that, so we needed to step back and consider the design process, do it in order to have in mind the customer before the program (i think that’s why we had trouble with the use cases in the delivery of the first partial).

The thing that i learned is that we need to follow like a timeline process and, if it is needed, iterate though it to refine everything and define new things that we might have not considered before. So in conclusion it’s everything about ORDER.

The software is still for the customer

Let’s talk about chapter 9 of the book.

Just the title of the chapter speaks so much: how many thimes they ask us for something and in the process we think about some modifications that we think will make it better and forgot what we were asked to do in the first place. I have had this kingo of thought when i had to help build a web page for some people, they gave us the designs and we were just supposed to make it look like that but honestly their designs were find of ugly to me so i had to keep reminding to myself that that’s what they asked me to do and that I should just stick to it.

They talk about how we must think about the user while we build our program, to think all the use cases we can with no limits, to be creative and expect everything to avoid a situation in which out program doesn’t work because we didn’t thought about something that the customer might do. For every scenario that we think of we must make our program work for it, guiding the user to what the right path is in case they make an unexpected action, and that the expected uses work perfectly.

Also, what called my attention is how they say that yeah, all that OO principles and practices that you use to build your program are very helpfull to you and makes things clearer and all but at the end of the day the customer doesn’t care at all about that, they just want you to deliver something that works and solves their problem. That’s why we must think about the client ALL through the process.

Anyways, that is all, enjoy a good song for the morning: