About two weeks ago I started an internship in a Software company. They like to use this relatively new framework known as Agile. But it isn’t only used where I work, it seems that a lot of companies are trying to migrate to an Agile approach (or some kind of distorted version of it 🙄).
In other words, they like using the SCRUM mindset.
In other words, Ken Beck has influence my work days and probably a lot of many other people.
So after doing a lazy Googleresearch I found out that the Agile roots (extreme programing) were mostly developed by a smart guy named Ken Beck. He did not just worked on this awesome methodology, but also contributed to Test driven development, Smalltalk, helped popularized the CRC cards along Ward Cunningham, and made the unit testing framework JUnit. It’s incredible all the work this guy has contributed into the Software industry.
Kent Beck (right image) Was one of 17 authors of the Agile manifesto which shaped the constant changing software industry
So what about TCR?
Kent Beck proposes: TEST && Commit||Revert which basically consist in:
If I fell that something wrong happened in my code then I can go back to the last time it worked. Therefore, the incentive is to make small changes, all in a stable way. It’s better to have many smaller commits than a big commit with all the different changes.
This doesn’t mean you will have to write more tests. But if you are going to make 3 tests at once maybe it’s better to test one by one so the code of the 3 don’t fully disappear. As Kent Beck says:
How could you make progress if the tests always have to work? Don’t you make mistakes sometimes? What if you write a bunch of code and it just gets wiped out? Won’t you get frustrated?
And yes, the mistakes will be made, we are humans and the human factor will never assure to have working code 100% of the times. But it is better to instantly wipe out all the bad code. So if you don’t want for big chumps of your work to be sent to the forgiveness then don’t make really big commits between the successful tests.
I guess most of us, university students that hadn’t finish a Testing course, program either by submitting the whole code project until the end, until it’s working as a whole. I’m not counting much the team projects because we commit occasionally, but, it’s a different reason. I think we commit to share code, not to have it safe for testing. And even deeper I guess we don’t do any formal testing.
TDD vs TCR
Test Driven Development: Also created by Kent Beck (is there anything this guy can’t do?), is basically a programming practice where you have to write test first and then write the code that will pass it. Finally do a refactoring.
I don’t have a lot of experience with TDD to be honest. To be even more honest I wasn’t even sure about what it really meant. I guess my testing before this class was running a program, if something goes wrong fix it. And occasionally throw as many weird inputs to see what happens. But I want to change this. Maybe TDD is the solution, maybe not.
Test Commit Revert: It’s an alternative workflow. TCR is chaotic in a sense that there will be different problems. Maybe TCR will be very weird in Github. To have a lot of tiny commits, for 12 line of code seems incorrect. But there are some solutions as squash commits. If all test passes then commit to master, if anything fails use the the revert button, Life is too short for waterfall planning.
Hello my name is Kevin Oswaldo Cabrera Navarro. In the next 3 months I’ll be writing about Software testing, verification and quality. So why does Testing and quality matter?
Quick example of why quality is important sometimes
I wonder if there was any quality department inside Sony pictures that didn’t realized about how bad does the idea of this movie actually is. This is the equivalent to the story about how small testing can save tons of money to a company. Probably the correlation is so arbitrary, but it is a good example of why everything should have a quality measurement (it doesn’t matter if it is a movie, a book or a software system)
No bugs in here! 🦗
One of the main goals in this blog is to prevent the usage of the word bug to refer to a fault, error or failure in a program. Maybe it is a word rich in history but in this blog I will try to follow the advices of Paul Ammann and Jeff Offutt writers of the Introduction to Software Testing book to don’t encapsulate all the different meanings into only one word.
But that’s another history for a different post. See you later