Ugh A Textbook Reading…Or? Wait what’s all this!

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

The beginning of this book really made me feel comfortable with the reading to come. To be honest I was dreading this assignment because of the reading. However, it really reassures the reader of the purpose of the book and kicks the basic textbook mantra. Something I found quite interesting about Dave’s story was that he had failed multiple times and he still found his way into the field. He actually had help from others but it seemed to be that the most help he got was going out on his own and finding a source of his own that he could understand before he could understand the sources (or basic textbooks) that were given to him. As a new programmer myself I like this idea, sometimes your own path is longer, but perhaps a smoother one for your development. 

A great thing about this book and chapters 1-6 is it’s romanticism of the future of programming and programmers and the formulation of a guide for them. They want to see the future ‘emerge’ without repeating past mistakes just like in the medieval Europe example, the past was riddled with abuse and mistakes. I enjoy the many examples of authors who express the ideas that failure and new ideas are key in this industry, in anything really. The best thing you can do is give the effort and use failure to formulate a map and acquire a “growth mindset”. It really has the sense of a pep talk in it, it not only inspires me to keep on reading but to remember to push myself in my efforts in software development. Sharing of knowledge also seems to be a key trait to have in this industry. Helping others to grow can also help yourself to grow, I like the idea of swallowing pride and asking for help or opening up to another when you are asked for help.

Emptying the cup Chapter 2 was probably the most interesting and simply eye opening chapter for me. It was like seeing someone else get slapped for doing something that you are also doing. I see the same mistake in me as I do in them. I have learned Java and C and whenever granted the possibility of exploring something new I have always chosen to be a creature of habit and to recede into what I know best. Well maybe what I know best isn’t what is best for me. At such an early stage in my development I should certainly explore more, even just the introduction of this chapter was powerful in making me realize that.

I also really enjoyed chapter 4 Accurate Self-Assessment. I often use the term big fish in a little pond when discussing one of my other personal interests, music. Performing music pays to be a big fish in a little pond but at a certain point one will realize they’re pond is tiny in comparison and therefore so are they. It’s okay to be content with that but I find success in growth. I think it’s important to outgrow your pond and move on to another. I think it’s important to ‘be the worst’, you can only go up from there and mistakes and failures will help you grow! I’m glad to see I can  relate more of my personal self to this reading.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

After starting work on our front end code we needed to create a method to allow users to search our database for a specific ‘artist’ name or by all artists that contain a specific letter or String entered by the user. For example, if the user input the letter “A” then they would be presented with a list of all artists whose names start with “A”. In order to create this function we needed to start with the backend.

In our Java rest api we needed a get method to search our database. The query in SQLite would be “select * from artists where name like ..%”. The “..%” is where the name of the artist we are searching for would go, but since we want the query to be unique to user input the “%” basically acts as a “don’t care”. This allows for whatever the string is that the rest of it doesn’t need to be specified and all artists will be returned that contain that string. To allow our users to input the string to be searched for we setup the query slightly differently in our backend. We use the query “select * from artists where name like ?”. The question mark acts as an operator to take user input. Then we use the statement:

statement.setString(1, name + ‘%’);

This statement sets the string we’re searching for to the first (and only) input from the user and then adds “%” after the string. Here’s a look at our full method: 

@GetMapping(“/artists/{name}”)

public ResponseEntity<Object> getArtistByName(@PathVariable String name) throws SQLException {

   PreparedStatement statement = 

conn.prepareStatement(“select * from artists where name like ?”);

   statement.setString(1, name + ‘%’);

   ResultSet rs = statement.executeQuery();

   ArrayList<Map<String, String>> results = new ArrayList<>();

   while (rs.next()) {

       Map<String, String> temp = new HashMap<>();

       temp.put(“ArtistId”, rs.getString(“ArtistId”));

       temp.put(“Name”, rs.getString(“Name”));

       results.add(temp);

   }

   return new ResponseEntity<>(results, HttpStatus.OK);

}

Then in our front end Typescript code we connect to the rest api backend with this method:

getArtistsByName(str: string): void {

 this.error = null;

 let tempStr = str.replace(” “, “%20”);

 this.http.get<Artists>(‘http://localhost:8080/artists/&#8217; + str)

   .subscribe(response => {

       this.searchArtist = response;

       console.log(response);

     },

     (error: HttpErrorResponse) => {

       this.error = error;

     }

   );

}

This method allows us to get all the results to the front end so that we can then print the results on our web page for the user to see. We continue to do this by implementing our html code to display these results in drop down lists for the user.

The idea of our project developed into a web page that allows users to search through a database of music artists and their albums and allow the user to select an album that they wish to download. They cannot truly download music from out web page but this is a framework for the idea of a web page with that purpose.

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Mockito is a framework in Java that creates Test Doubles for users that can be used with Junit. Test Doubles as described in my last blog are basically simplified tests for your code that more or less test setup over functionality. They are used to help you make sure you are setting up your code correctly in the early stages before it gets overly complicated. It’s good practice to test at this early stage in the process because simple setup and organization errors can become an overwhelming problem further down the line if you don’t find them early on. Mockito is a great framework to help you quickly generate these Test Doubles. Mockito creates mock objects with dummy values to make sure tests pass, as long as your setup is correct.

Check out this code example:

package com.journaldev.mockito;

import static org.junit.jupiter.api.Assertions.assertEquals;

import static org.mockito.Mockito.when;

import org.junit.jupiter.api.Test;

import org.mockito.Mockito;

import com.journaldev.AddService;

import com.journaldev.CalcService;

public class CalcService1Test {

@Test

void testCalc() {

System.out.println(“**— Test testCalc executed —**”);

AddService addService;

CalcService calcService;

addService = Mockito.mock(AddService.class);

calcService = new CalcService(addService);

int num1 = 11;

int num2 = 12;

int expected = 23;

when(addService.add(num1, num2)).thenReturn(expected);

int actual = calcService.calc(num1, num2);

assertEquals(expected, actual);

}

}

This code uses a mock() method.

To continue reading about this example check out this website:
https://www.journaldev.com/21816/mockito-tutorial

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Test Doubles is a term used to describe code tests that are basically imposters of themselves. They are unfinished and simplified versions of what the actual tests would be. Thus, they are doubles of their true forms. Theses doubles are written in order to satisfy and verify that you code is functioning and is setup at the most basic level. Test Doubles contain three different types; Stubs, Mocks, and Fakes. Each of these types is used in a different way to help get your testing going but without getting too complicated. 

A fake test allows us to take a shortcut when testing functionality. Say you have a database that your code connects to. Instead of starting up and running a connection you could have hard coded values in your code that you retrieve for your tests. So in this way you aren’t really testing the right values but that your code is able to get values at all.

A stub has a similar idea with using hard coded values to satisfy your tests. Essentially all you do is create a test, then make sure that the code that is being tested has exactly the results that are expected. For example, if you’re testing if a rectangle object is a square then you don’t actually create the rectangle, instead you return the expected value to the test class.

A mock is used when we just want to verify that our code is being called or accessed correctly without actually functioning the way we are intending. If you have a method you want to make sure is called correctly you can have that method be empty but when it is called it prints a string “Method … accessed correctly”. This way you know that you are calling the right method without having to actually test its functionality yet.

Here is a link that helps explain these Test Doubles:

https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Path testing is a great way to ensure that your code is concise and understandable. It allows you to see the flow of your code and the direction in which it travels depending on conditions, loops, and the order of the code. The name is self explanatory you are essentially testing the “path” of the code. This kind of testing is not in the same field as something like a Junit test. This is a visual test that doesn’t use software persay. It’s more like a diagram that allows you to test and figure out the logic of your code. Here is a diagram I found online that helps explain this type of testing.

In this diagram you can see that the numbered nodes match up with the lines of code. This helps to make the details of the code abstract and to bring the path of the code into the forefront. This isn’t very detailed code but it shows how conditionals effect the path of your code. Certain nodes are passed through and others are not depending on these conditionals. Setting up these diagrams for your code can help you understand your code better and thus eliminate redundant testing or create more useful tests.

Here’s a link to a website giving a good explanation of path testing.

https://www.guru99.com/basis-path-testing.html

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.