In this simple and straightforward guide of “5 Basic REST API Design Guidelines” . This guide shows 5 basic design guidelines that make a RESTful API robust and strong, it is key factor for API success. Each REST API design are different depend on what are the principles it for. The 5 basic design guidelines that make a RESTful API are Resources (URIs), HTTP methods, HTTP headers, Query parameters, Status Codes.

First is Resources (URIs), although we think naming is easy, but every have rule and constant. REST API unlike we use action verbs for other computer coding, RESTful use concrete names. URI case is naming resources in a program, there are 3 main types of case conventions. CamelCase has been popularized by the Java language, the main drawback is to be ineffective in contexts which are not case sensitive. snake_case has been widely used for years by C programmers, and more recently in Ruby. spinal-case is a variant of snake case which uses hyphens “-” to separate words. URLs are “case sensitive”, because of this reason it is recommended to use spinal-case.

One of the key objectives of the REST approach is using HTTP methods as an application protocol in order to avoid shaping a homemade API. use HTTP verbs to describe what actions are performed on the resources and facilitate the developer’s work handling recurrent CRUD operations. There are 4 main methods: the GET method is used to retrieve information from the given server using a given URI, a POST request is used to send data to the server, PUT method is to replaces all current representations of the target resource with the uploaded content, and DELETE is to removes all current representations of the target resource given by a URI.

HTTP header fields provide required information about the request or response, or about the object sent in the message body and query parameters which have 4 types paging, filtering, sorting and search.

Last is status codes, it is very important that make use of the proper HTTP. There are a lot of status codes, but the common use such as 200 – Everything worked, 404 – NOT FOUND – There is no resource behind the URI…

Resource modeling requires a careful consideration based on the business needs, technical considerations and cost-benefit. I thought this guide are simple and easy to follow. REST API should be simple and work as it intended to.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

I have heard the term “agile testing” thrown around many times in my classes and other conversations about software development, but I’ve never really known about what it means. When I was writing my blog post about the Scrum process (post found here: https://kathleenmlaw.com/2018/12/03/scrum-isnt-an-acronym-but-what-does-it-mean/), the term came up as well. Obviously, it’s pretty clear that agile testing is very important to software development. I did some reading about what agile testing entails, and found a couple of links which helped me understand more about its significance: https://www.tutorialspoint.com/software_testing_dictionary/agile_testing.htm and https://reqtest.com/testing-blog/agile-testing-principles-methods-advantages/.

Essentially, agile testing is an iterative process of collaborating between end users, the development team, and the testing team. Project development is based on the needs of the customer or the testers. Agile testing is a continuous process which begins at the start of a project or project sprint and remains throughout the course of project development, rather than just happening once as a “testing phase.” This makes the agile testing process more unstructured. Because testing occurs throughout the entire project, rather than just at the end, any errors that come up during development can be fixed at any time.

The amount of communication between all parties is also very high, with testers and developers working closely together to come up with project solutions that fit not only customer specifications, but also testing requirements. Because all parties (including the developers and end users) test the product along with the testers, there is decreased time waiting for feedback and ongoing discussions about how the project is going. Most importantly, every member is on the same page with each step of development.

There are several methods of agile testing that can be utilized during the agile development process: Behavior Driven Development (BDD), where development and testing is based on desired behavior of the program; Test Driven Development (TDD), where the tests to be passed drive the development process, and exploratory testing, where testers explore the program to be tested and then write tests based on what they find.

Here is more information on BDD and TDD, respectively: https://kathleenmlaw.com/2018/10/05/what-is-behavior-driven-development/ and https://kathleenmlaw.com/2018/10/12/more-about-test-driven-development/.

Some of the many advantages of implementing an agile testing environment include the incorporation of all members in the development process, the regular and consistent feedback received from all parties, and the flexibility that comes with continuous, synchronous work on development and testing.

I definitely feel more in-the-know now that I have done more reading about what agile development and testing entail. Now that I’m almost done with my undergraduate career, I’m excited to put these new skills to action in the workplace.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Throughout the semester, we have been learning a lot about good coding practice, which includes the implementation of various software design patterns. While we can try our best to fit our code into these design patterns, oftentimes this is not the case, at least for me. So, here is a list of several software design “anti-patterns,” or bad-practice patterns. My good pal James Blash (found at www.jwblash.com) gave me the idea to look more at these anti-patterns. The link that he recommended is https://sourcemaking.com/antipatterns/software-development-antipatterns.

This list has several great examples of different ways that code falls into more of bad practice. Here is a brief overview of some of the interesting design pattern problems that I found from this list.

• Cut-And-Paste Programming – This anti-pattern involves the reuse of existing source code, rather than programming new code from scratch. This can result in multiple errors of similar nature, as errors from the existing code can affect the rest of the program when pasted elsewhere. A fix to this problem utilizes more of a black-box reuse development process, such that the issue of reusing buggy code is more likely to be bypassed.
• Input Kludge – This anti-pattern occurs when behavioral testing fails because software accepting free text input uses “ad hoc” algorithms, which does not account for illegal statements or combinations of characters (e.g. strings when the input only accepts numbers, etc.). Solutions include the use of free parsing software or simply examining and possibly revising the algorithms to account for and properly handle “input kludge” being entered into the system.
• Golden Hammer – This anti-pattern occurs when developers use sort of a “one-size-fits-all” approach to coding; in other words, they take advantage of one or a couple of solutions to attempt to solve all other issues in their programs. A solution to this problem involves further education or training for team members to learn more about other ways to solve problems that arise, rather than just sticking to one familiar concept.
• Poltergeist – This anti-pattern uses poltergeists, or classes with very limited use throughout the program, but can potentially break the whole system when it isn’t there. Often, poltergeist classes start other processes taking place in the program. The solution reorganizes the class structure such that longer-lived objects in the program take on the responsibilities that the poltergeist(s) handled, thus removing the need for the poltergeist classes altogether.

Hopefully with this new information in mind, I hope to try to avoid some of these issues later in my classes, as well as my career!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

In class, we have started to look at mocking and how to implement this technique in our unit testing. I was pretty confused about how mocking worked, so I wanted to do more research on it this week. This  link has simple explanations of the premise of mocking, as well as other short, yet effective, examples of mocking: https://javacodehouse.com/blog/mockito-tutorial/ .

So what is mocking? In unit testing, we evaluate the functions of different classes and methods within those classes. These methods depend on outside classes, or dependencies, in order to function properly.

But what if the code for those other classes isn’t completed yet? Or, what if there are errors lodged in our dependencies, causing our methods being tested to fail? We still want to ensure that our methods are working properly, without depending on other classes’ behavior.

Mocking can be implemented here. Mocking simulates these dependencies to keep our tested methods independent. As shown in the picture below, the mocks eliminate the need for other classes or dependencies coming from outside of the methods that we want tested.

Image from https://medium.com/@piraveenaparalogarajah/what-is-mocking-in-testing-d4b0f2dbe20a

There are several mocking frameworks out there, including Mockito and PowerMock. We used Mockito in class, so I will be going over that framework more in this post, even though both have the same function.

First, we need to initialize our mocks. Our class did this differently than what is explained in this article, which shows the annotation @Mock for the classes that we want mocked at the beginning of the unit testing, and then using the following statement in our setup: MockitoAnnotations.initMocks(this).

Now that this is set up, we can start performing our testing! Two functions that we used extensively are the “when” “then” pattern, and the “verify” method. The “when” part of the “when-then” pattern passes in a function that requires use of the mocked class and returns a “stub” of the type to be returned from our mocked method. “Then” shows what is expected to be returned after completing our mocked method. “Then” methods can include “thenReturn(returnValue)” or “thenThrow(exceptions)” for different outcomes from the mocked method.

The “verify” method comes in handy when testing void methods. Because we aren’t returning anything, “verify” lets us examine, for example, if the void method is only being called once, that the correct method is being called, or that other void methods are being called instead of the one we want.

Reading this article was really eye-opening into the many different ways that mocking and Mockito can come into play, and I hope to work more hands-on with it in the future to learn even more about how it works.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

I’ve always been interested in the Scrum project management process, especially because we will be diving into it during my Software Development Capstone class next semester. I found a great link detailing the general methodology of Scrum, as well as specifying the roles of each party involved in the process: http://www.mountaingoatsoftware.com/agile/scrum .

Scrum is essentially a project management technique which consists of the completion of work through multiple shorter periods of progress, called sprints, towards the overall project goal. Before going over the overview of the Scrum process, there are 3 primary parties taking part in Scrum to be discussed: the software development team itself, the ScrumMaster, and the product owner. The software development team is a “self-organizing, cross-functional” group. The team does not have a leader amongst the group who delegates tasks and provides feedback. Rather, all of this is decided by the whole team. Each member of the team is also needed to develop each part of the project, from coming up with ideas, to developing solutions and features to satisfy goals of each sprint. This team has support from the ScrumMaster, who coaches the software team to perform Scrum at their best without telling the team exactly what to do, and the product owner, who serves in more of an end-user role and guides the team towards building the product best fit for the customers.

The Scrum process involves several sprints (commonly 2 weeks long). A planning meeting kicks off each sprint, where all parties create a list of tasks to finish by the end of the sprint, called the sprint backlog. A product backlog is also maintained and prioritized by the product owner, which details additional features to be added to the product and which features are most important to complete first.

Other meetings taking place during the Scrum process include daily Scrum meetings, around 15 minutes long, where the development team goes over what they’ve completed the prior day and what they intend to currently work on. The sprint review at the end of the sprint allows the development team to showcase their product, as well as the product owner to identify places to continue work for the next sprint. Finally, the sprint retrospective at the end of each sprint gives time for reflection of the Scrum process from the just-completed sprint and what needs to improve.

Reading more about this process has gotten me more excited about what is to come in the Capstone class next semester! This is such a great opportunity to take part in, especially while still an undergraduate student.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

The article that I read this week is about processing JSON data with Jackson. I thought this would be a good article to read after using JSON data a lot this week for processing input and output in our final projects, and since Spring Boot uses Jackson as the way for processing JSON. I wanted to learn more about how this works, especially after getting some errors when trying to pass in certain data types this week (particularly Calendar objects). This post goes over how to read and write JSON data to and from Java objects using Jackson for data binding. It does this by creating an example POJO to use for input and output. It creates a basic employee with the fields of name, ID number, address and other typical fields, it also has an object within an object by using an address within Employee that contains a street, city, and zip code. The article creates an example of this in a JSON input file and creates the necessary Java classes and then implements the Jackson methods (such as ObjectMapper) for databinding and outputting Java input as a JSON file.

I think that it was interesting to see how to do this with the Jackson implementation as a seemingly more proper method of converting JSON to Java objects and the other way around. Especially after spending the past week creating and getting our project to pass similar data back and forth between JSON and Java. It does seem out of the ordinary to me that both of the example classes don’t use constructors, instead using just set methods to create the object, but that’s how this implementation is supposed to work with Jackson. I particularly liked the Tree Model implementation in the article and was not aware that this was a way of processing JSON data. This article has definitely made me think more about the different ways of processing JSON data with web applications and REST APIs and the best practices to use when doing this, especially with larger, serious implementations for applications. If time permits for our final project, I would like to try and do a similar implementation in this article for our JSON processing. By doing this, it would make adding new objects to the database a lot cleaner (especially without needing a constructor) in the implementation than it currently is.

Source: https://dzone.com/articles/processing-json-with-jackson

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Greetings reader!

The nature of this blog is to give a short summary over a topic that is essential in the Computer Science field: JUnit Testing. I will be expressing my reaction to the content by sharing what I find useful and interesting. Without any further introduction, let’s begin.

The JUnit framework is a framework that uses annotations to show methods that specify a test. When defining a JUnit test, the test itself is a method in a class that is only used for testing. This is called a test class. To define that a method is indeed a test method, define it with the @Test annotation. This method implements the code under test.

Also when defining a test, testers can use an assert method, made by JUnit to check an expected result against the actual result. These method calls are called assert statements. Testers should provide messages in assert statements because it makes it easier for the user to identify and fix any problems. This works if someone looks at the problem, who did not write the code under test or the test code.

When naming a test, there are many naming conventions. A solution for classes is to use the word “Test” at the end of test classes names. This gives the reader an easier understanding that this is actually a test class. A test name should explain what the test does. If that is done correctly, reading the actual implementation can be avoided. If you are using the Maven build system, you should use the word “Test” for test classes. The Maven build system automatically includes such classes in its test.

Testers can also run their JUnit tests outside the IDE with standard Java code. Systems like Maven or Gradle can be used to execute tests automatically. The org.junit.runner.JUnitCore class provides the runClasses() method. This method allows you to run one or several tests classes. As a return parameter you receive an object of the type org.junit.runner.Result. This object can be used to retrieve information about the tests.

J unit testing is a huge part of unit testing and so much more can be said about it. This is just an intro or short summary of the topic.

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.

We’ve played around with different testing concepts like mocks and stubs in class, however since we didn’t dive too far into it, I decided I’d look a little bit deeper into the subject of mocking. I found this great overview of it on Michael Minella‘s blog.

Before diving into why mocking is helpful, let’s look at the purpose of mocks in the first place and what they even are. In class we had an example where a student object had a transcript object, and in order to get the student’s remaining credits or current GPA, the student would reference the transcript’s methods. Something like this:

If we wanted to test the Student’s getGPA() method, it would involve calling transcript’s getGPA() method. However, we don’t want to test transcript’s method, we want to test Student’s. How do we know Student.getGPA() does the intended thing, which is call transcript.getGPA()? In his blog post, Michael uses the example of a test that uses the ArrayList object in Java. When we write a test that uses an ArrayList, we don’t want to test the functionality of ArrayList — we want to test our implementation of it and trust that ArrayLists function correctly. Mocks are designed to solve this problem.

A mock is a temporary object that is used in place of the real object that would be used during a test. The mock has default values for all of it’s data types, and so whether or not a test passes is not dependent on the state of the other objects or methods inside of it. In the case above, transcript.getGPA() would return a value of 0.0 if a mock transcript object had been set up beforehand. This is helpful because it allows us to remove the potential puzzle of the functionality of the transcript’s methods and solely focus on the what the student’s getGPA() is actually doing. 

There are plenty of different mocking libraries to choose from (we used Mockito in class) and they all function in slightly different ways. The subject of mocking is a deep one, and there are seemingly infinite other concepts like stubs, fakes, dummies, and more which can all be used to ensure that your tests test are as thorough and reliable as possible. 

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Source: https://www.guru99.com/back-box-vs-white-box-testing.html

This week’s reading is about the differences between black-box and white-box testing. For starters, it states that in black-box testing, the tester does not have any information about what goes on inside the software. So, it mainly focuses on tests from outside or on the level of the end-user. In comparison, white box testing allows the tester to check within the software. They will have access to the code, in this case, another name for white-box testing is code-based testing. In this article, the differences in each type of test is listed in a table format. Let it be known, that the bases of testing, usage, automation, objective and many other categories will be different. For example, black-box testing is stated to be ideal for testing like system testing and acceptance testing. While white-box is much more suited for unit-testing and integration testing. The many advantages and disadvantages of each method are clearly defined and provides a clear consensus on how each method will pan out.

What I found useful about this article is the clear and concise language it uses for describing each category for each category. Unlike other articles I’ve come across about the topic, they beat around the bush and make it difficult to discern the importance of each type of testing. Many of the information provided by this article can be supported by activities done in class. One of the categories labeled time labeled black-box testing as less exhaustive and time-consuming, while white-box is the very opposite. I somewhat agree with this description as with white-box testing, you will have much more information to work with. Every detail of code can in some way be processed into a test as deemed necessary. The overall quality of the code as stated, is being checked during this test. While in black-box testing, the main objective is to test the functionality, which means it’s not as extensive of a test in general. Also, what struck as interesting was the category Granularity. With a single google search, yielded the meaning “the scale or level of detail present in a set of data”. Low for black-box and high for white-box, which rings true for both tests. In conclusion, this article reinforces prior knowledge on the differences between black-box and white-box testing.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.