Skip to main content

A Review of Mockito

For this week’s blog on quality assurance, I wanted to review what we learned most recently in class. I decided to watch a relatively short (24 min) tutorial on Mockito. It has been over a week since I’ve seen it, and there’s another few days until we meet again. I could use the refresher before then.

The tutorial I chose to watch was by a YouTuber named Walter Schilling. I thought he explained the concept very well. I will definitely bookmark his page for other concepts that I find challenging.

I thought it was a little bit of a complicated set up. I don’t think it was necessary to see the UML diagrams or as extensive of a walkthrough of how his code worked. He didn’t go excessively in depth, but I understood it pretty well after he gave a  demonstration of the final code in action. (He typed in some inputs and showed what the output would be.) I didn’t need to know as much information on his example code. That’s not what I had come to see.

When he got to the mockito section, I was surprised at how little there seemed to be to it. I remember when we went over it in class, I didn’t think it was a very difficult concept, but I probably could not have done it without a little bit of review. After watching this tutorial, I have renewed my confidence that I am able to do it again.

I could see how someone might not like that his method wasn't polished and rehearsed. He would say something such as, "Why is that giving me an error,” or "I don't think I spelled [my variable name] correctly." It didn't take him long to diagnose any of these problems. I kind of liked this style. It gave me more confidence in my own abilities when I could sometimes diagnose something as quick if not quicker than he did on his own example. (To be fair though, most of them were simple fixes.)

Towards the end of his video, all of his tests were failing, and he couldn’t figure out why for a moment. Something small that I gleaned from this is that no matter how good you get, no one is ever perfect. I have a habit of putting myself down for not knowing everything or making simple mistakes. I should not be quite so hard on myself. Even the experts make mistakes. You could go one step further and say that if they never made mistakes, they would never learn from them and become experts.

https://www.youtube.com/watch?v=8PgH0PwgEa8

Comments

Popular posts from this blog

Data Structures Primer

I've been a tutor for this past semester to students taking Introduction to Programming. Many who have come to my session are moving on to Data Structures next semester. They asked if they could have a primer as to what to expect. I have some resources that I have found helpful both while taking the course and tutoring it in the past. It will take me a little bit to compile a good list of those, but for now, here is a bare-bones list of topics of topics you might expect to see for a data structures course: Part 1: - Running time of code segments (Big-O Notation) - Abstract Data Type (ADT) - Interfaces (when to use "implements", cannot instantiate them, what inheritance is) - Superclass, subclass, method overriding/overloading - Abstract classes Part 2: - Binary Search Trees - Stacks (and its four methods — push, pop, peek, empty) - Linked list (single, double, circular) - Prefix and postfix notation (compare to infix) Part 3: - Min/Max Heap - Hash Table...

Apprenticeship Pattern “Practice, Practice, Practice”

The apprenticeship pattern framed the problem is that if you do not have room to make mistakes in your day to day programming, you will not have room to grow. The next line hit close to home, “It’s as if you’re always on stage.” I learn quite a bit from my school assignments, but I don’t always think I have mastered each area before moving on to the next topic. The problem arises when I know my code could be improved upon, but it’s currently working. I don’t want to restructure my code too much, because I’m afraid of making it worse. The term comes to mind, “If it ain’t broke don’t fix it.” I have problems with this way of thinking, but when you’re pressed to make something work before the impending deadline, “good enough” is sometimes feels like the only option I have left. This pattern champions a different approach to this kind of mentality. I like the idealized version that they have laid out based on the research of K. Anders Ericsson. This describes where a mentor would ass...