Today I will be talking about testing software! More particularly, testing by using dummys! So what exactly is a dummy and why do we use it in testing. Dummys are objects that are created for the purpose of testing but are actually never used. Think about it like a mannequin. The mannequin displays the clothes as how they would look on a human, but the mannequin is not actually a functional human, and does not actually use the clothes. Its only job is to make sure the clothes look (or function for the sake of testing) correctly. According to this blog by Tom Winter, “How our test data generator makes fake data look real”, our test generator makes fake data look real for the purpose of testing our code. Why would we ever want to test fake data? The easy answer is this: sometimes we do not have all the data or all the code finished, and we want to test our code without having to play the waiting game. Sometimes it is even impossible to test our own code without dummys because we do not have access to the actually data. So we use these dummy objects to play the role of the real data (which we do not actually have access to, remember?) in order to test our code to ensure it functions properly.
Testing with dummy objects is something we have been doing in my software program at school, and I happen to find it very useful in the sense that I do not actually need the data to make sure my code works. Not only does this help pick up testing efficiency, but it cuts down on the overall wait-time between developers and getting their product out. On the flipside of things, if another developer was waiting for me to finish my code before testing, they could use a dummy to test their code instead of rushing me to finish, which could possibly lead to me making mistakes and end up slowing down the entire development process. I enjoy being able to test right away, and using dummys can help with this. I hope to continue using dummy testing in the future, as it is an easy and very effective method of testing!
Here’s the link: https://medium.freecodecamp.org/how-our-test-data-generator-makes-fake-data-look-real-ace01c5bde4a
Today I will be talking about Gradle! For this I will be referencing a blog on gradle called “Why Build Your Java Projects With Gradle Rather than Ant or Maven?”. This article discusses the pros and cons of building Java projects with Gradle instead of similar programs such as maven and ant. The blog starts by talking about how project builds used to be sort of a simple process that did not have to use fancy applications such as Gradle, ant, maven, or any other build program. Most requirements for builds just entailed packaging and compiling software. As mentioned in the article, as we now are seeing an increase in high tech programming and agile formatted programming, the requirements for building/compiling/packaging software is a much larger process. So why does this blog prefer gradle to another build program such as ant or maven?
One of the top reasons this article prefers gradle is because it is simple and user friendly. One big thing this article mentions is that when using build tools frustration is a common encounter while trying to use these tools. I personally have had this frustrating experience with maven about two or three semesters ago when we were using build tools in our software class. Building with maven was a giant headache and had to be done through linux, so if you happened to be one of the few who don’t primarily run linux (Yes, that is sarcasm) then you had to use a linux subenvironment in windows and run maven through there. However when you ran maven through that, it did not have access to your windows file explorer unless you mounted your C drive every time you wanted to explore files. This was a giant headache for me, and a problem I have not encountered with Gradle. Gradle can be used simply through a git bash terminal or any other terminal on your host operating system, for that matter. I personally enjoy the ease of gradle. Building with gradle is as simple as running “gradle build” on your master branch and it will build and let you know if there are any errors and what they are. You can also run html versions of your test reports to get a very detailed debugging without having to do everything in the terminal. I personally have learned a lot from using gradle and I look forward to using gradle more in the future to build my projects with ease.
Here’s the link: http://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608
Hello! Today’s topic of discussion will be path testing in software development. The article that is up for discussion today is “Path Testing: The Coverage” by Jeff Nyman. So let’s get right into it. What exactly is path testing? Path testing is a method of testing that involves traversing through the code in a linear fashion to ensure that the entire program gets test coverage. The point of path testing is to make a graphs that represent your tests. This is done by graphing out your program by nodes, which are used to represent different lines of code/methods/bodies of code. The connections between the nodes represent their linear relationship. If a program graph is made correctly, you should easily be able to identify the flow of the program and things such as loops should be distinctly represented. So what’s the big deal with testing using these program graphs? When we are testing we want to make sure we test all of our code and our relationships between different parts of code. If we use nodes as these different parts of our code, we can test using the program graph layout by making sure that every node in our program graph is traversed during testing, as well as every relationship between the nodes. This is an important concept to ensure that your program gets 100% testing coverage, and to make sure that the different parts of the code work together as they properly should.
I have drafted a few different program graphs for programs in my testing class, and I have to say that they make the objective of the code entirely clear. By objective, I mean I can tell exactly what is supposed to happen in the code and the exact order of execution. Loops are entirely clear in these graphs because the are represented by a line going from one node looping back up to a node above that. If there are 2 nodes in between the first node and the node that loops up to the first node, then I know that nodes 1-4 are a loop of some sort, and that nodes 2 & 3 are some sort of method body that do some action within the loop while node 1 is the beginning of the loop and node 4 is the exit condition node. You can test the edges between the nodes to ensure the different relationships for the nodes are correct as well as test the nodes themselves to ensure they work as desired. I think that program graph testing is a great way to visualize testing and I hope to use it a lot in the future.
Here’s the link: http://testerstories.com/2014/06/path-testing-the-coverage/
For today’s blog I will be discussing the topic of testing with mocking. I recently read an article called “Mock? What, When, How?” by Lovis Moller. So let’s jump right in. What is mocking in terms of testing? Think about your code as a giant puzzle. All the pieces fit together, but they fit together in specific ways. Say you’re missing a piece of the puzzle because your partner hasn’t finished their part of the code yet. The new problem is this: how can I test my code without my partner’s piece of the puzzle? The answer is by using mocking. Mocking allows us to emulate or “mock” our partner’s puzzle piece that we are missing so that we can test our code without having to actually have the rest of the puzzle pieces. So mocking seems like a pretty good idea and like something we should use all the time, right? Wrong. The article talks about some of the pitfalls of mocking, which we will now talk about. First, the article says to mock only code you own. Do not mock third-party code simply because it’s not yours and you do not know how it works or how it should work. Another rule of thumb is to avoid mocking values and concrete classes. You should avoid mocking values because the objective of mocking is not to test for specific values, but rather it is meant to test the relationships and interactions between different classes (pieces of the puzzle). Concrete classes should not be mocked because of all the extras (methods, unused lines of code, etc) that come along with the concrete class. It is more efficient to use mocking with an interface in this case.
In the past few weeks we have been doing testing with mocking in our CS class. I think it is a really neat and useful way to test because you can get stuff done on your end without having to wait for someone else to finish. In a world where we work as groups to complete projects, human error is always an issue. We could have our parts of the code done weeks before a deadline while our partner waits until the night before the deadline. Problem here is that we might not be able to proceed in testing and fixing our code because what our code does as a function relies on our partners code. We certainly do not want to wait until the night before a deadline to test and fix everything. Mocking helps us with this by emulating the code we are dependent on. I hope to use this more in the future.
Here’s the link to the blog: https://blog.codecentric.de/en/2018/03/mock-what-when-how/
For today’s blog I am going to be referencing another blog called “What is Boundary Value Analysis and Equivalence Partitioning?” by Ulf Eriksson. The article talks about boundary value testing being a way to test values between the valid input ranges in test cases. Boundary testing is important so that we as testers can figure out where our valid input range lies, and we do not mistakenly use inputs outside of the valid range (the invalid range). This is also important to do so that if an end user does enter an invalid input, then the program knows how to handle it rather than crashing and burning. One other area the article talks about is called equivalence partitioning. This one is a little different from boundary value testing in that it divides the test into a range of values and selects one input from each range. This is a form of black box testing because you are testing the value without knowing what is going on inside and in turn, not knowing the exact output. There is, however, an expected output that you determine before testing and it will be proved either true or false based off the actual output of the test. The best way to differentiate between boundary value and equivalence partitioning is summed up very nicely in the article. The basic idea of the point being made in the article is that boundary value testing is testing for the valid range of inputs whereas equivalence partitioning is slicing that valid input area (as determined in the boundary value tests) into equal parts and selecting one value from each partition to test. I think this is is a very constructive way to test within a valid value range because you are getting a “good spread” of test values. In other words, the test values you are getting will be from across the spectrum of valid test values because of the equal partitions and selecting a value from each partition. I have been using this idea of equivalence partitioning in class by selecting test values such as min, min+, nom, max-, and max. We have learned in my software class that testing from each of these values will give you a good showing of how accurate your tests are and how good your tests are. Thinking about these five test values as equivalent partitions within the valid boundary range will help me find these values easier in the future.
Today I will be talking about a blog called “Unit Testing, How to Write Testable Code and Why it Matters”. This blog talks about the importance of unit testing for anyone who is a software developer. The blog talks about what unit testing is, what it consists of, and something that I had never heard of until today; the three A’s of unit testing: Arrange, Act, Assert. We will talk about these three A’s of unit testing in more detail later. Another thing the blog talks about is unit testing vs integration testing. The blog sums up the difference between the two as unit tests have a narrow scope to test just one small part of the program whereas integration tests test how the “pieces” of code fit together and work hand in hand. Essentially, integration testing is a larger scale version of unit testing. So what exactly makes a good unit test? According to the blog, good unit tests consist of tests that are easy to write, readable, reliable, fast, and truly unit testing (not integration testing). This is where the three A’s of unit testing come into play. After you make sure that your unit tests adhere to the rules of good unit testing, you can apply the three A’s of unit testing. The three A’s (as mentioned before) are Arrange, Act, and Assert. Firstly, we arrange. We do this by testing small portions of the code (unit tests) to ensure they work as designed. Next we give the test some sort of input to “test” its function to make sure it works correctly, this is also known as the Act phase. Lastly, we Assert what we know our output should be and we then compare it to the output of the function we are testing.
I think this is an extremely important article because it has given me a lot of insight on how to make good unit tests and how to make the testing cycle easier by remembering the three A’s of unit testing; Arrange, Act, Assert. I hope to use the three A’s of unit testing in my future programs in hopes that my testing will go smoothly and quickly. Another thing the article talked about that cleared up some confusion for me is unit testing versus integration testing. For me, the two have always been kind of interchanged and intermingled, as they are very closely related. I think that many people know there is a difference between the two, but do not know exactly what that difference is. It is good to think of it as integration tests being larger scale unit tests. In my head, I now think of integration tests as being made up of smaller unit tests, and seeing how those unit tests work together. I think this article was overall a really good read and will make my approach to writing tests for my programs change for the better.
Here’s The Link: https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
For today’s blog I am writing about agile testing. I found this blog on agile testing called “A Coach Guide to Agile Testing”. The blog talks about the different types of agile testing and the different types of teams/groups/personalities that use agile testing in different ways. The article mentions that people who use traditional ways of testing usually do not like agile testing because they consider it a threat to their job, which is to identify discrepancies between the working system and the specifications. This is different from agile because agile does not have specification documents that are detailed enough to help the tester do their job. Something I found interesting about this article was when they were talking about the traditional testers and their approach of “follow specifications and report how the system differs from these specifications”. The article says that checking to see how closely the program follows the specifications does not actually say anything about the quality of the program. I think this point really hit home, because you can make a program that follows the specifications to a tee, and it can still be a poorly designed or poorly running program.
For an example, say you are building a program to manage someones bank account. You would need methods to deposit, withdraw, check balance, transfer money, etc. Now let us say the only specification for the program is that it compiles and runs. We could write a program that compiles and runs and in the sense of traditional software testing, we have a passing program. However, what if the method for deposit didn’t actually add money into the account, or the method for withdraw added money instead of taking it out? According to traditional software testing we have a functional program, when in reality we know our program does not do what it is supposed to. This is where agile testing comes in handy. Agile testing will test every method in our program (not just the specifications) to make sure that our methods actually do what they are supposed to. This is why I like agile testing, and try to do it in all my programs. It is a good way to assure you have a quality product that functions as designed and has also been tested and passed. I hope to continue using agile testing in my future programs and reading this article has given me some new tips and tricks to think of when doing agile testing.
Here’s the link: http://www.softwaretestingmagazine.com/knowledge/a-coach-guide-to-agile-testing/