Author Archives: tempurashrimple

Week 18B – C Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll continue with one I’m not the most familiar with, C! I’ve worked in small amount of C in classes at Worcester State, but have little experience outside of that. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

If you haven’t already read my other blog post on Python testing, feel free to read it right here!

For learning about unit testing in C, I consulted this article on the subject: https://interrupt.memfault.com/blog/unit-testing-basics

It seems like unit testing in C is a lot more barebones compared to Java, which in my experience utilizing C, makes sense for the language. A lot of features primarily used in Java, like object-oriented structures aren’t available in C (to my understanding, could totally be wrong).

For one major aspect, there seems to be only one assertion command in C, just simply “assert”. Theres no assertTrue, assertFalse, assertThrows, or assertEquals, just simply “assert”. And from the example given below:

#include <assert.h>

// In my_sum.c
int my_sum(int a, int b) {
  return a + b;
}

// In test_my_sum.c
int main(int argc, char *argv[]) {
  assert(2 == my_sum(1, 1));
  assert(-2 == my_sum(-1, -1));
  assert(0 == my_sum(0, 0));
  // ...
  return(0);
}

It seems the “assert” function comes from the <assert.h> library, much like the JUnit librarys used in Java. But more importantly, it seems that “assert” is the equivalent of “assertEquals”.

It also seems like Unit Testing in C is best implemented with tools outside of a compiler for C. The ones mentioned in the article in specific were CppUTest, Unity, and Google Test. For the rest of the article, the use examples using CppUTest. It was interesting to hear one of the options being called Unity, which is the name of a game engine, which, while not written in C, is written in a mixture of C# and C++, which are both offshoots of C. Makes me wonder how testing in a gaming engine works, perhaps it’s something to look at in a future blog post, hint hint, wink wink.

CppUTest seems to implement the same SetUp() and Teardown() functions that JUnit can employ, which is really good, as these methods are important for testing multiple methods. It also seems to have more then just an Equals assertion, even though the example used is another equals example.

This gets me more interested in C, as I have been told understanding C allows you to understand other languages much more clearly. Perhaps I’ll take a deeper dive some day, who knows! Until next time, my readers~!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 18A – Python Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll begin with the one I’m the most familiar with, Python! I’ve worked with Python in small amounts in the past, and have an understanding a lot of it’s syntaxes are similar to java’s, albeit simpler. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

For this, I’ll be looking at the official page for unittest on Python’s website, here:

https://docs.python.org/3/library/unittest.html

Right off the bat, I’m really interested in the fact that unittest is actually based directly off of JUnit! Which means a lot of the syntax, formatting, and framework is quite similar, just modified to fit the mold of Python.

Looking at the snippet they gave as an example…

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

In this, it seems the way you define test blocks is by having a class with (unittest.testcase) and then doing “def” to define each test case.

Even the assertions are the same and written near identically, as the first three use assertEqual, which is identical to javas assertEquals, minus the s, and assertTrue and assertFalse, which are also identical to their java counterparts. assertRaises, which is used in the third test, seems to be Python’s equivalent to assertThrows, however, it seems to be a bit different in comparison. assertRaises seems to identify a specific kind of exception being raised, whereas assertThrows would just identify any exception in general.

The last line also is a block of code that allows an easy way to run all the tests, so when you run unittest.main() in a command line, it will automatically run all the tests and display the results.

There also seems to be a whole bunch of different command line options to display results and modify the ways in which its run. As an example, theres “-v”, which stands for verbosity, much like the bash command, which shows the results of each individual test being run, like below:

test_isupper (__main__.TestStringMethods.test_isupper) ... ok
test_split (__main__.TestStringMethods.test_split) ... ok
test_upper (__main__.TestStringMethods.test_upper) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

It seems extremely interesting and makes me want to learn more Python, which would definitely help me in my career in all sorts of ways! Next blog we will be looking at how unit testing works in C. Until then!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 13 – Benchmarking

This week I had a bit of trouble thinking about what to write…until I lucky remembered what went on today. That being the Benchmark Trailer for Final Fantasy XIV: Dawntrail, a benchmarking tool that made sure your pc was up to specifications for the new expansion pack, but also tease some of the new gameplay, locations, animations and classes to come with it!

Which got me thinking…benchmarking is a great tool when it comes to testing not only hardware, but also software too! I think the two go hand in hand, “the two” being software and hardware, when it comes to testing. And then it hit me what I should write about: I should talk about what a benchmark is, and why it is important to testing!

For this, I consulted our favorite search engine, Google, and found this site!

https://testsigma.com/blog/benchmark-testing

So, what is a benchmark exactly? According to this site a benchmark “is a subset of performance testing that refers to a set of metrics or a reference point against which you can quality check your software or applications. The purpose of this testing is to compare the previous, present, and future updates of the application against a set reference.”

Now lets break that down a bit into digestible pieces…basically, every time you create a set of tests or even a set of functions for a program, you wanna make sure its always working, whether that be in general when its compiled, or on different device. Say you want to ship out a program to users on both Windows AND Mac. Youll want to create a benchmark environment where you can test and see how well the program functions on those.

There’s various ways you can do a benchmark, either by checking the programs functionality and tests on a Virtual Machine, testing it on hardware that differs from your own, or even running it on a frien’d computer as opposed to your own.

The reverse is true as well, as seen with the Final Fantasy Benchmark shown above. The test, while it sees if the functionality works on certain machines, it also lets you know if your machine/hardware is also unable to run the software. Sometimes your hardware might be so outdated that certain kinds of software are incompatible or unable to be run due to the older processing systems or runtime of the machine.

I am interested to see if we cover this at all in class, as it definitely seems like something that is a major part of testing when it comes to both hardware and software.

But thats all from me, until next week!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 12 – Comparing Tips

For this week, I wanted to look at what some websites consider helpful tips when it comes to testing software in Java and compare that to what we have learned in class. By looking at each tip one by one and comparing it to the things Professor Wurst has taught us during our lectures.

For this, I will be looking at this website: https://www.code-intelligence.com/blog/11-tips-unit-testing-java

Tip Number 1 is to “Compose Tests before Writing Code”, which is actually what we have been focusing upon for the last few weeks, so it’s good to see that this is being reaffirmed

Number 2: Keep tests small and concentrated. This is another subject that we’ve been looking at as well, as we’ve been looking at strategies on how to concatenate code for test.

Number 3: Defining your Code Coverage. This isn’t actually something I believe we’ve spoken about in this class, however, we have discussed similar things in my previous classes with Process Management.

Number 4: Isolating Tests from External Sources. This one Im not sure if we have discussed it, but it also seems like a given, considering we have been taught to always only use tests in test classes and to pull from testing packages when importing.

Number 5: Automate wherever possible. I don’t actually think we’ve done this yet in Testing, however, this is something we have discussed previously in another class, I believe in Software Design. If you can automate something, always try to.

Number 6: Creating Mock Dependencies. This isn’t something in specific we’ve touched upon yet I feel, however it makes sense. I feel as though when I did our first homework, I kind of did something similar to this.

Number 7: Use Assertions. Yes. Absolutely we have done this in class. All if not most classes we have written use assert.equals(), assert.true(), or assert.false(), amongst others.

Number 8: Using proper names to test methods. This is something we learned way back in CS101. Always name your methods something understandable for you and your team to instantly know what it does. Never write gobbledygook names for methods, be concise.

Number 9: Keep Unit Tests Up to Date. I don’t believe this has been taught yet as most code we have worked with has been static and unchanging. However, Im sure we will have assignments where we focus on this harder. It definitely seems like something that is extremely important, as code changes so too should the tests, or else they wont work properly or even give false positives.

Number 10: Don’t Focus on Implementation. This one is interesting to me. We haven’t really spoken about implementation of code when it comes to testing. It’s very interesting to me because I have never really thought about this before, but it definitely makes a lot of sense to me. Something good to keep in mind for the future.

And lastly number 11: Create independent test cases. I actually unfortunately learned this myself the hard way with the first homework, as each class was accidentally dependent of one another if ran back to back. It’s something I definitely need to keep in mind going forwards.

And thats it! It’s definitely a lot of overlap which is great to see. Until next week!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 9 – Better late than never.

Jesus, yeah I’ve kinda been slacking on my blog writings huh? So sorry for the radio silence coming from this place. Going forwards I can hopefully write every week moving forwards.

Anyways, for my first time writing for this class with Professor Wurst, being Software Quality and Testing, I wanted to talk specifically more in depth about what I had already sent him earlier this semester in our course’s Discord server, that being a video by Matt McMuscles about Sonic The Hedgehog (2006)

I have personal experience with this game, as I specifically remember going to BlockBuster when it was still around, wanting to get the game LittleBigPlanet, and my father reaching into the the bargain bin to find Sonic 06, as its better known to fans (quite the mouthful the real title is, and better to differentiate it from the original game on Sega Genesis), and handing it to me. Unfortunately, I had left the store only with Sonic 06.

The reason I relate this to Software Quality and Testing, is because this game is a heavy example of what happens when you rush it, as the video shows. This game was rushed out to shelves for the Christmas of 2006, so SEGA could make a good profit off of it, benefitting off of the increased demand that comes with Christmas.

Many things in this game show that it was improperly tested, with bugs, glitches, and even crashes all about the game. The game is held back due to this, as there is a proper and interesting idea underneath the surface. However, the lack of finding these extremely prevalent bugs and glitches lead to this being one of the worst selling titles in the Sonic franchise.

This goes to show why testing and quality assurance is so important, even in the gaming field. Video Games are software after all, just specifically for entertainment and enjoyment.

I specifically wanted to cover this for this class because it shows me why making sure the testing is as fluid as the programming to create a perfect product. This is especially true in the gaming field, which I hope to have a future in.

Needless to say, I don’t own my own copy anymore. I snapped my PlayStation 3 disc a long time ago. And months after I got it, I did end up getting LittleBigPlanet, and played it way more than this travesty.

tl;dr dont get the game in bargain bin.

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Old Blog, New Year

Hi! I believe we’ve already met before, my name is Rai, and Im a student at Worcester State University. Im writing a new introductory post to welcome myself into the new year and to welcome myself into my new courses.

As for a little about me, I’m huge into video games and anything that flexes my creative muscle, which is why I’m going into a focus of Software Design and Development for my Junior year. I’ll be taking CS-443, Software Quality Assurance & Testing, with Professor Wurst, and as a part of that course, I’ll be writing for this blog ?

I hope to utilize this blog throughout my career, but for now I’ll simply be using it for this course and any other courses I take with Professor Wurst.

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 14 – Token #2 – CS-343

For this blog, I specifically wanted to look into how this class relates to the preferred field I want to go into, which is Game Design. I wanted to see what kind of languages would be used, what kind of design elements are implemented, and even in the case of frontend vs. backend, how online games employ servers.

However, it seems like I had a misunderstanding that these two positions were similar omewere, as I find many sources that say software design vs. game design are a completely different beast, which only made me more interested. I did some more research, and this lead me to end up reading this article below:

Specifically I noticed that software development has more rigidity when it comes to designing and delivering a product. Software engineers are usually employed to design a software to meet consumers demands, which usually entails specific features and options they’d want in the software you’re developing. Whereas with game design, you have a much more flexible development cycle, as theres a lot more creativity involved. You’re less focused on making sure specific features are available and more focused on delivering a product that is unique and interesting for consumers, and keeps them engaged.

Game developers also rarely work with programming languages when it comes to development of products. Game developers mainly use engines, which are interfaces that employ programming languages to create building blocks to build off of to create a video game. Software engineers mainly work with the code directly at almost all times, making sre each line is properly written. That’s not to say some game devs don’t work with code directly, some do, and many Triple A companies actually write their own engines using their own code, like in the case of Epic Games’ Unreal Engine, which is used to power their famous game Fortnite.

Something this article notes is that software developers may not need to worry about performance compared to game developers, and I can understand why they might say that. Games rel on having a fluid and enjoyable experience, and that is dependant on the performance of a game, making sure theres no glitches, bugs, or lag. However, I would argue that performance is still a factor within software design too, because what if a simple calculation process in a program takes multiple minutes? Consumers will still have an issue with that. While I do think it’s definitely a lot more important in game development, that’s not to say it’s not unimportant in software design.

And that’s all my blogs for this semester! I’ll be taking another of Professor Wursts classes next semester, so I’ll likely be writing again then. See all you readers come January!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 14 – Token #1 – CS343

For this blog I’ll be using one of my tokens for this class so I can hit the 6 blog minimum before the semester is over.

In this blog post, I wanted to look more into JavaScript since I didn’t really know too much about it. I struggled with the backend homework we had because I never knew anything about the syntax or language at all. So, I want to learn a bit more about this language within this blog. For this, I consulted this website, and gave it a good hearty read:

https://developer.mozilla.org/en-US/docs/Web/JavaScript

This site gives an overview of JavaScript and the applications in which it is used in general, and what benefits and downsides it has compared to other languages.

What I found very interesting is that I originally knew that JavaScript was mainly used for website development and coding, but this site gave some examples of applications such as Node.js and Adobe Acrobat. I believe we’ve actually utilized Node.js before in our classes, but I can’t quite put my finger on what exactly we used it for, but I recgonize the name appearing in one or more of the repositories we’ve been working with.

It seems like JavaScript is much like Java in the sense that it can use object oriented code, but I think the similarities between the two end there. In the past, I always heard that JavaScript was a completely different beast from Java, and after look more into it, I see why. This site below describes the differences:

https://www.lighthouselabs.ca/en/blog/java-vs-javascript

JavaScript it object-orientedcode, whereas Java is object-based. That may sound the same as each other, but there is some very specific distinctions between them. Java relies on objects to function, whereas JavaScript has functionality for objects and suggests use of them with it’s language, it is not required. JavaScript is also a lot more fluid with it’s syntax, and has a lot more free-form and flexibility with it, which reminds me a lot of what I’ve heard about Python. Java is a lot more rigid, and requires specific pre-set uses of it’s syntax.

But back to JavaScript, it seems like its The language for web design, as a lot of it’s language is made with web design in mind. My future for this area of study is some form of design in technilogical areas, so it would be possible I go into Web Design. If I do, I’ll definitely have to teach myself more JavaScript. It seems like a really useful language to have on hand in that case.

I will be posting one other blog today, using another token, so stay tuned for another!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 14 – Blog for both CS-343 AND CS-348

So for this blog, I wanted to find a topic that is applicable to both classes, so I wanted to look more into GitHub and the ways it functions compared to GitLab.

I duplicated by Secret Santa Generator repository from GitLab: https://gitlab.com/worcester/cs/cs-348-01-02-fall-2023/students/bpoole/secret-santa-generator and duplicated it in GitHub here: https://github.com/TempuraShrimple/Secret-Santa-Generator

To do this, I had to open up the local repo on my PC, create a new blank repository on GitHub, and run the following commands:

Once this was done, my repository was transferred over to GitHub successfully, without harming my GitLab repository in any way shape or form. Everything, including the history of the repository, was included with this transfer, which I think is really cool.

One difference I immediately noticed between GitHub and GitLab is that GitHub allows you to add a short description on the right-hand side of the repository, allowing a quick way to figure out what the program intends to do without having to look at the README.md. Obviously if you want more information, the README.md is very important in that case.

Both sites have a really good planning structure, with GitLabs’ issue boards, and GitHub’s project tab, which is structured very similar, but I think GitHub’s might be better as it allows you to choose from a lot of different templates like Kanban, Team retrospectives, and bug tracking, which I think is really cool. You’re also able to customize it as you please, so you’re able to set up a scrum structure like we did in GitLab for many of our projects. However, after looking into it, if you want to utilize Scrum, it seems GitLab is definitely structured better with preset pillars that are made with Scrum in mind. However, it’s a toss up on which would be better to utilize in this case for project management, in my own humble opinion.

GitLab also has some advantages in the construction and development aspects of this comparison, as after looking into it, GitLab is able to automate releases and builds of code once they are ready to be done so, and GitHub doesn’t have this capability at all.

https://about.gitlab.com/competition/github/?stage=Configure

This seems extremely useful for a program that has set deadlines and not enough time to do these things during, say, a Sprint. It allows a lot more flexibility with the work being done in a repo and can allow a lot more efficiency and productivity. I will definitely look into this more later on when I start using this repo I cloned myself.

All in all, after looking things over, it seems like GitLab has a lot of additions that make it better over GitHub in all sorts of ways, and I’m surprised GitHub is used more than it. I should probably introduce my friend I’m working with on GitHub for his game engine for this if he ever develops a much bigger team, as many of the planning-oriented inclusions GitLab has would be extremely beneficial!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 12 – 12/3

For this week, I wanted to talk about the creation of comic books, and how it relates to Software Process Management and Software Design. Within the article linked below, it describes the process of how a comic is created, and the steps needed to reach a final project. I specifically wanted to look more into this as the process is quite similar to how software is developed.

The first step is coming up with an idea for what the comic would be about. Some stories might be a story needed to be told to convey a message or present a solution, which is things that we have been learning about in Software Process Management. Or perhaps you have a creative idea you want to put out there, which can relate to the creation of software on your own, like we are doing in Software Design.

The second step is writing a plot, which is much like creating a backlog for your process, planning the beginning, middle and end of the process.

Then, its off to creating the art, which is a multi-step process, which is much like creating the code. For the artists, they need to sketch, then line, then ink and even maybe color the panels of the comic, which parallels how code will need a framework, then main code, supplemental code, and comments to build on top of each other. This process isn’t always in a predetermined order, and can vary from project to project.

And then theres editing and review. Everyone looks over the draft of the work they’ve made, and then tweaks whatever needs adjustments as needed. This process might lead to the recreation of art or code, depending on which process we’re discussing. Once a review gets a pass, they’re ready to finalize and move onto the last step, which is…

Publishing and marketing! Once you’re done, you send the finished copy of the work to consumers to receive, and perhaps you’ll even advertise it, if its not well-known. This can include things like advertisements, sponsorships, and even word of mouth.

The parallels of the dynamics in which these processes interest me a ton as someone whos also minoring in art, and wants to go into a digital design or digital-art focused field, whether it be game design or webcomics. It’s kinda awesome to see that theres a sort of venn diagram between my two passions, and that they can intersect.

EDIT: I meant to post this earlier before, but I had connectivity issues and it never posted when I thought it did. I only realized because a friend wanted to read my blog, haha. To clarify, this blog is intended for Week-12, and for both classes, not 13, it just was posted late due to issues. My apologies for this inconvenience.

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.