The next apprenticeship pattern I took on was Draw Your Own Map. The premise is simple: you are the only person who can choose the paths you go down and which roads you travel. You should not leave yourself to the mercy of your situation and those around you to determine the course your future will take. Is is a definitely a pattern of self-determination.

The Draw Your Own Map pattern is absolutely useful. I have always been a person who has difficulty relying on others. Although I acknowledge this as a weakness in most ways, one way it has strengthened me is I usually don’t find myself depending on others for approval or assistance. If I want to do something with my life, or make some future plans, the only person I ask is myself. This independence and selfishness is important, in my opinion. There is only every going to be one person looking out for your best interests: you, and so therefore it is your sole responsibility to map out your future and make the decisions that will lead to your happiness.

Despite this, I do think there are limits to the pattern, even when applied to careers. For example, although your position in a company might not be immediately satisfying, with time there is potential to move throughout the company to a position that is better for your skills and abilities. There are some paths you can only get to by travelling on a bumpy, gravel road first. It’s not optimistic, or ideal, but the text definitely glossed over these potential scenarios where you prioritize long term gains over short term happiness.

Overall, Draw Your Own Map is not an interesting or a surprising apprenticeship pattern, but it is a hugely useful one and one I feel I’ve already been using to make college-related decisions for a long time anyways. Basically, only you can make the choices that will lead your life to happiness, nobody else will do it for it. Just as long as you are making ethical choices that don’t tread on anybody else’s map.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

GivenWhenThen

Blogger Martin Fowler in his self titled blog describes a template for organizing unit tests, called “Given, When, Then”. This concept is perhaps a rephrasing of what we discussed in class, the four phase test, or “Setup, Exercise, Verify, (teardown)”. The idea is to structure our test cases in a logical, easy to understand process.

Fowler describes the idea as “essential to breaking down writing a scenario (or test) into three sections”. Given a specification, any situation we need to test for can be broken down into these three steps. The first section is “given”, or the “setup”. During this phase of the test, we would create variables and set up the preconditions to a test. Fowler uses a scenario of trading stock to illustrate his point. “Given” a certain amount of stock to invest (precondition) move on to the next phase.

The next step in the model is the “when” phase. During this phase of testing, we are choosing the behavior of a function to be tested. In Fowler’s stock trading example, this translates to “Given: x amount of stock to sell- When: I want to sell y stock”.  This phase essentially defines the behavior of the test we are writing.

Last but not least, the “then” phase is all about putting the first two cases together and verifying them. Following Fowler’s stock example, the “then” phase is represented as “Given: x amount of stock to sell – When: I want to sell y stock – Then: I should have x-y stock”. This phase is where you verify the expected behavior to the actual behavior of the program.

Personally I find this model particularly helpful, in the sense that it provides a useful narrative for breaking down testing situations. To me the “given-when-then” model seems more intuitive than “arrange, act, assert” or “Setup, exercise, verify”. While all three models definitely describe the same process, I think that this model is the most clear. In any case, breaking down test scenarios into discrete parts like this is integral to creating clear, easy to understand tests.

From the blog CS@Worcester – Bit by Bit by rdentremont58 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: Mutation Testing. This blog will share my analysis of Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial.  I will be expressing my reaction to the content by sharing what I find useful and interesting and displaying if I have any concerns or disagreements. Without any further introduction, let’s begin.

First, let’s start with defining what mutation testing is. Mutation testing is a testing technique that uses the structure of the code to conduct the testing process. It is simply the rewriting of code in small ways in order to take out the excessiveness in the code. This wordiness may cause failures in the software if it is not altered. It is very sneaky because it can pass through the testing process’ unnoticed.

There are three types of mutation testing: value, decision, and statement mutations. Value mutations are efforts to change the values to display errors in the programs. The change of the value is usually to either a very large value or a very small value. It is found that the most common strategy to combat this is to change the constants. Decision mutations are when the code is changed to check for errors in the design. Ways to fix these errors are by changing the arithmetic operators to find the failures or by altering the relational and logical operators. Statement mutations are when changes are done to the statements by deleting or rewriting the line.

Mutation testing is based on two theorems. The first is the competent programmer theorem. This theorem explains that most software errors made by experienced programmers are due to small syntax errors. The second theory is called the coupling effect. The coupling effect says that simple errors can couple to form other faults.

All in all, mutation testing is a fairly simple technique that is used when testing code. Sometimes errors or faults can be hidden when making tests that will cause the source code to fail. Mutation testing is the process of altering these subtle errors in efforts to run the code.  This topic is extremely important to this field because it gives us a deeper understanding of our errors, which helps greatly when correcting “bad” code.

Source: Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial

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

Using the Simple Factory design pattern is a lot like making cheesecake

Software developer Sihui Huang, writing for the blog freeCodeCamp, explains the simple factory design pattern in terms that most people can appreciate – cheesecake.

Huang walks us through the basic steps in a simple factory for creating cheesecake. Starting with a number of his favorite types, he creates a makeCheeseCake() method which calls cheesecake.makeCrust, cheesecake.AddLayers, etc. The makeCheeseCake() method uses the type of cheesecake as a parameter, and calls the the steps to creating a cheesecake that all different types have in common. No matter what kind of cheesecake you are making, you still need to make the crust. So the makeCheeseCake() method is only concerned about the steps required in making any kind of cheesecake, it doesn’t care about what flavor the particular instance is. Huang describes this concept, as we have in class, as encapsulating what varies.

So Huang goes on to create a cheesecake factory class that handles all the different classes of cheesecake we can possibly create, and returns the appropriate cheesecake type by a createCheeseCake() method inside the factory class. The trick is that when you call the makeCheeseCake(), a new cheeseCakeFactory object is created, and uses the createCheeseCake method to determine what type the cheesecake is. So now the MakeCheeseCake() method does not need to know at all about what kind of cheesecake it is creating.

By separating the parts of a program that stay the same from those that vary, we can simplify adding and modifying different types of an object (in this case cheesecake) by adding a new class and adding to the cheeseCakeFactory class. No code has to be rewritten to accommodate for changes and removals of types of cheesecake.

Personally I enjoy Huang’s analogy to elaborate on the simple factory design pattern. Being able to separate varying parts of a program from parts that never change makes our code more understandable, coherent, and easy to modify. And the idea that a “factory” can handle the details of initializing different types of objects instead of having separate implementations for every object type is good design, and I think the cheesecake factory example is a good metaphor for encapsulation

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

For this week’s blog post, I chose this blog by Lucie Saunois. It talks about the differences between Black box, Grey box, and White box testing for software or applications.

Black Box Testing

Black box testing reviews only the functionalities of an application. Testers do not really know the internal structure of the application. Testers typically have a “user” profile. This method aims at checking if the final stage of the application works like its supposed to. Common things the tester would look for in a Black box testing are missing or incorrect functions, interface, performance, program initialization, and external database access errors. To do this test, each different user has their own scenario to test, and all functionalities must be tested.

White Box Testing

White box testing reviews the functionalities of an application as well as its internal structure.  All of the internal components of the application are tested through the source code. Testers have a “developer” profile and not a “user” profile unlike in Black box testing. White box testers need to have competence in programming since they need to understand the source code. It is mostly done in the developing stage of the application. Therefore, it allows them to test the data flow and the handling of exceptions and errors. Scenarios for this test are created by the testers based on the source code. Testers only check if the code produces the expected results.

Gray Box Testing

Gray box testing is a compilation of both Black and White box testing. Gray box testing tests both the functionalities and the function of an application. In this test, the testers know the functionalities and also the internal structure of the application, however, they do not have access to the source code.

This blog explaining the differences between each kind of testing is really easy to follow. The way they were describe was easy to understand. She also wrote about their benefits and drawbacks of each method of testing. I really find her examples interesting towards the end of the blog where she uses an analogy by comparing it to testing a car system. I think finding blogs like these would help anyone understand the different testing methods out there, it is simple but very informative.

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

Ever since I picked up my first Java book and read through it, one thing always stuck in my mind when it came to writing any program and that is to not repeat yourself when you don’t have to. Leonardo Brito wrote an interesting piece, “Don’t obsess over code DRYness”, and he gave a few good points on why we shouldn’t try to make our code as complex as we can. He starts off by saying that we, as humans, are good at pattern recognition but sometimes we over-do it. He uses the example codes below:
____________________________________________________________________________
# Example 1
class Car
include Checkups

def maintenance_10k
check_break_fluid
check_battery_terminals
check_engine_oil
end

def maintenance_30k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
end

def maintenance_50k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
check_gearbox
end
end
____________________________________________________________________________
# Example 2
class Car
include Checkups

def maintenance_10k
basic_maintenance
end

def maintenance_30k
basic_maintenance
check_spare_wheel
end

def maintenance_50k
basic_maintenance
check_spare_wheel
check_gearbox
end

private

def basic_maintenance
check_break_fluid
check_battery_terminals
check_engine_oil
end
end
____________________________________________________________________________
After DRYing the code we see that it produces a new method called basic_maintenance while the original maintenance method conveys exactly what the method is expected to do. He then added a change such that we no longer need to check the break fluid on the 10 thousand miles checkup, so now we must remove the method check_break_fluid from basic maintenance and only add it to the upper maintenance methods. What he was trying to illustrate is that although one set of code was easier to read and follow, a simple change could have us altering out code in more ways than we’d like.

Brito talks about the trade off between some duplication over the wrong abstraction because overly DRYing your code could result in more confusion than simply repeating SOME code which is where he introduced another concept: DAMP – descriptive and meaningful phrases. The purpose of these two terminologies is to guide is to write better code and not going to any extremes.

I found that the concept of over DRYing your code interesting because I never thought about it that way and that there was a such thing. I’ve heard of DRY but never DAMP so I found that amusing how they’re opposite from each other. Looking back at my projects I feel as though I stand somewhere in between both concepts. I try to not over-do simplifying yet at the same time I make sure I apply DRY when necessary. I agree with what the author said about repeating sometimes to make it easier on yourself in the end.

Thank you for the read!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

For every person, there are things they like and things they don’t. One such thing for me is testing my code. Is it laziness? Is it the fact that I’m awful at it? I’m not particularly sure why but in “5 Reasons why you should test your code” by Frank van Wijk, he talks about five important reasons on why we should always test our code.

Reason number one: Regression testing. The example he gives is that your code is fully functional and working but then one feature breaks in your code and now you’re left staring blankly at your code. Given that if you have 100% code coverage, you know there is a fully functional test suite. For example, you run the test suite, then you modify some parts of your code and then you run the test suite again. Now if tests are failing after the modification, there is an assertion done for this case. This is good because after every modification or as your program becomes more dense you could repeat this process each time to get rid of newly formed bugs.

Reason number two: Improve the implementation via new insights. After you finish your writing your program the first thing you might want to do is walk away grab a beer and reward yourself but before doing so you should write start writing tests for your methods. If you find that it is difficult to write tests for your methods then in may be an indication that there is room for improvement in the way you wrote your methods.

Reason number three: It saves you time. Although it takes up a huge chunk of your day writing tests for your code, in the long run it would actually save you time. The reason being, if you refactored your code, your tests should catch most of the bugs and allow you to fix it without having to sift through the entire program searching for what went wrong.

Reason number four: Self-updating documentation. There are many ways to understand code; read comments, read the implementation, or by reading the tests. It serves as a type of documentation that allows the reader to know what is suppose to happen.

And the final reason Wijk gives is because it is fun.

For the most part I found this blog quite fun to read because the author made a few valid points. Writing tests may be a pain but in the end it does make you a better programmer and ensures that there is less room for errors. I know my biggest weakness is testing my code because I never have in the past and moving forward I will start to.

Thank you for the read!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

I’m a Computer Science major, about to graduate this year, without a real understanding of where to go after my degree. Since my future is fairly open, I was curious to research the professional QA field and how some testers got their start in the industry. After a quick google search, I followed the link below and found some helpful insight from current professionals on the topic.

https://techbeacon.com/6-new-careers-paths-ideas-software-qa-testers-professionals

Firstly, it surprised me to find out that many QA testers ended up in their positions without a lot of intention. To quote QA professional Shelley Rueger, “I don’t know that there is a standard way to start in QA.” Originally, Rueger went to MIT to become a research physicist, quite a long step away from her current career of 15 years so far. Its surprising to me how somebody could invest so much into their future but mysteriously end up in a different field entirely, a trend common across all majors. I suppose the future is just that unpredictable, which actually offers me relief since I’m so unsure of where I’ll end up.

All that being said, going into QA is certainly worth planning out long term if anybody is considering it professionally, since the first few years are typically rough. Jeremy Hymel, the QA manager at QAlytics, shares his experience; “The early years in a tester’s career are rough, the pay is not great, and they are not treated as well as developers.” Once the hardships are over however, this article lists multiple points to jump off of as a QA tester. I will summarize the following paths: Product Management, DevOps, and Customer Experience.

Product management is a common fit for advancing QA testers, since they have extensive experience ensuring the best software possible. This quality is essential to the success of software reliant companies and they will often recognize a good QA tester to take the role of feature development.

Testers are more suited than software developers in the advancing role of DevOps. QA testers can easily practice the skills needed for a career in release management, product stability, or automation engineering.

It also makes a lot of sense that a QA tester could pursue a Customer Experience role. The tester assumes the role of the customer with every software test, therefore they have plenty of experience seeing the point of view of the user.

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

In this portion of the Individual Apprenticeship Patterns, it gives an overview about how the new coming of an apprentice can impact a development team that is filled with well-experienced craftsmen or developers. Apprentices by their nature are new, and inexperienced first hand, and therefore they are open to learn ideas and techniques used by the craftsmen around them. Assuming that most of the experienced craftsmen have 10-20 years experience, they are unable to further their skills because their only primary concern is to just get the job done or delivering the next project.  In order for a development team to improve its dynamics with new ideas and techniques, the apprentice can be one of the main components to improve or repair the team’s passion and enthusiasm.

“Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar.”

The quote struck out to me because it shows the apprentices can give in or succumb to the ways of the experienced developers. As an individual, I want to be the type of person to bring enthusiasm to the team and to allow a flow of passion and excitement into the team. To me, maintaining a positive vibe and atmosphere allows everyone in the team to communicate effectively and consistently.

“On a team that is open to the excitement and contributions of an apprentice, you will provide some unique qualities that more experienced developers rely upon, such as unfettered imagination and enthusiasm. This is the time in your career when it makes the most sense to take risks and speak your mind. You have very little to lose. Your ideas and passions will add intelligence and diversity to your team.”

I found this quote extremely useful because it supports my idea that as a team member, having a passion about the work environment or project can bring positive outcomes for the team, and good things will happen. I fully agree with this Apprenticeship pattern because it promotes an amusing and enjoyable atmosphere for every team member, which can be traced back through the conscious or subconscious actions of the apprentice.

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

The “Confront Your Ignorance” pattern offers the next steps after you’ve followed the “Expose Your Ignorance” pattern. It’s not enough to admit that there are gaps in your knowledge; an apprentice software developer needs to be willing to do the work to fill in those gaps. The book suggests several ways to go about this. You might read introductory articles about the subject, start making a breakable toy, ask experts and peers if they’re willing to share their knowledge, or learn alongside someone else. Personally, I think learning with breakable toys would be the most effective strategy for me. I understand what’s going a lot quicker if I can try something myself and see it in action. I’ll also keep in mind asking peers and mentors. A lot of the time, I won’t be able to figure out something that’s obvious to someone who already has knowledge in a certain area on my own.

The writers emphasize that this pattern needs to be used with “Expose Your Ignorance.” Confronting your ignorance without exposing it means fostering a culture where failure and being seen learning are shameful and must occur in secret. It will also probably be more difficult and time-consuming if you don’t ask for guidance when you’re stuck. Exposing your ignorance without confronting it means you won’t be able to solve any problems outside of your particular niche, and others won’t appreciate it when the gaps in your knowledge prevent you from fulfilling your responsibilities.

This is also the first time the writers have mentioned a situation in which you should prioritize the job over the apprenticeship. It’s possible to be so caught up in your drive to learn more that it gets in the way of delivering the product. You might also be tempted to go about solving problems in a way that helps you learn what you’re trying to learn, but is impractical for others. You should be striving to improve your craft, but not at the expense of your team and your duties. Part of being an apprentice is putting the needs of your community before yourself. These guidelines provide a good balance between the greater goal and what’s more immediate.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.