This a new start, a new phase here in the academy this is called the open-source phase. Let's talk about the goals first and how I'm going to go over a lot of things because, once again, I don't know how to do everything that I have to do. Just like in other phases let's break big problems into little problems and try to solve them one at a time.
I'm just going to write a summary of the goals, I'll go more in detail in the monthly journal, I just want to keep track of what I'm doing, I want to tell you a story. Let's get to it! these are some goals of the phase:
As you can see I have to submit at least four valid contributions, I don't know how I'm going to do this, but I don't have time to feel bad or another similar thing... Let's go dive into it right now!.
Now I'm going to break things down here. I'm going to have two sections, In one section I'm going to write down the activities or things that I learn during the week regarding the open-source project, and in the other section I'm going to be talking about new technical stuff that I learned.
First of all, to collaborate on an open-source project first I need to know what is open-source, so let's get to it!.
From here: What is open source?
"Open source is a term that originally referred to open source software (OSS). Open source software is code that is designed to be publicly accessible—anyone can see, modify, and distribute the code as they see fit."
This means that I can collaborate in any open-source project because the source code is open and anyone can see it and add features or enhancements to it. Open-source software also has a license which means that anybody can come to take the code modify it and even re-distribute it.
Now I need to know how to contribute to Open Source
We can find a really good article How to Contribute to Open Source
We can do a lot of things for a project, not everything has to be code, if we other skills we can still add value to a project. We can add design, organization, documentation, and other things that aren't code.
But for now, we can actually work on code. In this part, we could, find an issue and tackle it, work on a new feature, automate project setup or Improve tooling and testing.
A project also has documentation. These files are usually listed at the top level of a repository.
We could choose some projects that we already use and we know that have issues or things that could be improved. But we have to be sure that is a good project to work on. We have to check how many contributions have per week if it accepts contributions, the number of issues or PR to check if is an active project.
Before doing anything, do a quick check to make sure your idea hasn’t been discussed elsewhere. I think we all should do that because we need to know what is happening before really doing anything.
Now we are ready to go over an issue or enhancement.
To do a pull request we need to:
Could happen 4 things:
But any way you really did it!
Now we have a clearer idea of how to do it. Let's choose a project and try to get context.
I liked this project because it's like a playground for developers or people interest in security and the app is coded to be vulnerable and is also part of OWASP that's why I liked it.
It's a web app that is using Java, HTML, JS, and CSS. The interesting thing here is to research how to code vulnerable code, how the vulnerability works, and the important thing here is that we have to find a use case for each vulnerability.
I also like this project is also from OWASP and is a security program and vulnerability management tool. I like these security-oriented projects and this one is also great because of the things that it works for.
The challenge here is to learn how to use docker and Django, which is also kind of research to do it.
This week I'm going to be working on unit testing on the software project that I did in the last phase so let's read and try to understand some new concepts about unit testing and JUnit.
A software test is a piece of software, which executes another piece of software asserting that it behaves in a certain way.
With software tests you ensure that certain parts of our software work as expected. These tests are typically executed automatically via the build system and therefore help the developer to avoid breaking existing code during development activities.
Unit testing:
Integration tests:
JUnit is a Java test framework and an open source project hosted at Github. JUnit 5 (also known as Jupiter) is the latest major release of JUnit. It consists of a number of discrete components:
- A JUnit test is a method contained in a class which is only used for testing. This is called a Test class. To define that a certain method is a test method, annotate it with the @Test annotation.
- This method executes the code under test. You use an assert method, provided by JUnit or another assert framework, to check an expected result versus the actual result. These calls are typically called asserts or assert statements.
- Assert statements typically allow to define messages which are shown if the test fails.
- A widely-used solution for classes is to use the Test suffix at the end of test classes names.
- As a general rule, a method name for a name should explain what the test does.
- One possible convention is to use the "should" in the test method name. (menuShouldGetActive)
- Another approach is to use given[ExplainYourInput]When[WhatIsDone]Then[ExpectedResult] for the display name of the test method.
Source: JUnit
The 3A pattern is simple and provides a uniform structure for all tests in the suite. This uniform structure is one of its biggest advantages: once you get used to this pattern, you can read and understand the tests more easily. That, in turn, reduces the maintenance cost for your entire test suite.
- The arrange section is where you set up the objects to be tested. You bring the system under test to a desired state and configure the dependencies: either instantiate them directly or prepare their test doubles.
- The act section is where you act upon the system under test. You call one of its methods: pass the dependencies and capture the output value if any.
- The assert section allows you to make the claims about the outcome. This may include the return value, the final state of the SUT and its collaborators, or the methods the SUT called on them.
Source: Making Better Unit Tests: part 1, the AAA pattern
We will keep learning about unit testing, but for now I need to read about mockito for my practical section
- In your unit tests, you want to test certain functionality (the class under test) in isolation. Other functionality required to test the class under test, should be controlled to avoid side-effects.
- A mock object is a dummy implementation for an interface or a class. It allows to define the output of certain method calls. They typically record the interaction with the system and tests can validate that.
- Mock frameworks allow you to create mock objects at runtime and define their behavior.
- The classical example for a mock object is a data provider. In production an implementation to connect to the real data source is used. But for testing a mock object simulates the data source and ensures that the test conditions are always the same.
- Mocking or mock frameworks allows testing the expected interaction with the mock object. You can, for example, validate that only certain methods have been called on the mock object.
- Mockito allows you to create and configure mock objects.
- Using Mockito greatly simplifies the development of tests for classes with external dependencies.
- Mocks can return different values depending on arguments passed into a method.
- The when(….).thenReturn(….) method chain is used to specify a return value for a method call with pre-defined parameters.
- The thenReturn() methods lets you define the return value when a particular method of the mocked object is been called.
- Mockito keeps track of all the method calls and their parameters to the mock object.
- You can use the verify() method on the mock object to verify that the specified conditions are met.
- You can verify that a method has been called with certain parameters. This kind of testing is sometimes called behavior testing.
- Behavior testing does not check the result of a method call, but it checks that a method is called with the right parameters.
- verifyNoMoreInteractions(Object) also verifies that all stubbed methods have been called during the test
I'm working on unit testing of one of my previous projects. Once again thanks to my mentors for helping me out with this, I'm learning a lot. Let's go through this piece of code that I did.
- First of all, I want you to notice the name of the method and the annotation. The annotation defines that as a test method. The name is the given[ExplainYourInput]When[WhatIsDone]Then[ExpectedResult] approach this gives a clear idea of what the method is going to test.
- The second thing to note is the 3A pattern structure first we define the given or the arrange section where we define objects to be tested and some dependencies for the test. The when is the act section is where we execute the actual method. The assert section allows you to make the claims about the outcome or we compare the results or what we expect.
- The first section is where we mock the repositories because we want to isolate that part. Here we use mockito to do that.
- In the last section where we verify any changes in the data and we also verify the interactions, the method calls in this object. We are doing a behavior test. Mockito also helps us with this part.