This method talks about how there are tools that we need to master but we may not always understand how to master them. A lot of the times we try to be a master of all, when in reality that doesn’t necessarily work all of the time. What I mean by this is that when we are faced with  a task, sometimes we think we understand each little aspect of the specifications. However, upon actually tackling that task, we aren’t really sure where to go. Like one of my previous entries on “Exposing Your Ignorance”, confronting your ignorance really focuses on selecting on skill, tool, or technique and really honing in to fill gaps in your knowledge about it. One of the points in this method that really caught my attention was it’s mention of humble, ignorant, and dependent team building. If you are working with a team of developers and each team member has this ideology that everything is “just because of the way it is”. this can lead to a multitude of problems.

One of these problems is bad team building. When you assemble a team of people for some sort of project, you want to be able to work together to share ideas. If a problem arises you all want to be able to come together and understand what the issue is so you can solve it as a team. If you all think that things are just the way they are because they are, this can often lead to disagreements among team members. Some team members might even think you are against them just because you disagree with them on something. It’s this idea of confronting your ignorance that is vitally important to understand. You should learn one thing at a time, that way when a problem arrives, you can put aside  what you know, and focus on what you don’t know. Failure in a public place can be embarrassing, but it is exactly these failures that make it better. If you failed at something, you wouldn’t want to be ridiculed for it. Instead, you should learn from it and always be willing to learn more and more about the issue.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

To continue with chapter four “Accurate Self-Assessment”, int his chapter we learn how to assessment ourselves. We learn our value in the team, how to work with each other. Everyone is beginner of craftsman at one point. We all at some point is a new apprentice on a project. This is where you’re unsure of your place on the team, and the team is unsure of you. This is not just when you are new software developer, its also apply to you are new to the group.

“Sweep the Floor”, a job not a lot of people want to do. Everyone in the group should contribute same amount of work, but that’s not always the case. Most people would want to be the best craftsman, but there are other important job that need to do. One way I discover while at school, to get group trust when you are newbie to the group is be active volunteer for work. We want to show our desire to work, it is the easy way for group get to know you. Also, a great way gets to know how the group operate/code design from bottom up. For example in the book, task as “maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.” This is do so for the group benefit. There are also a few negative consequences, your teammate also takes you wrongly as someone who doing job that no one else will do. You will not have opportunity to do changeling one. If we know our value, though our hard work we can earned their trust. With this mentality, we have the flexible to be in any environments. This also apply when there is other new addition to the group, you can understand them and show them the right way.

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.

This week, I read all about an apprenticeship pattern titled Be the Worst. This pattern details the benefits of being surrounded by people who are smarter than you and have more experience than you. The idea behind the pattern is that the more time you spend around others, the more information you can learn from them. Why spend your time figuring out a problem somebody already solved when you can learn the veteran’s way of handling it from a colleague? Surrounding yourself with more advanced developers can help build your skills and gain experience in ways you wouldn’t if you were learning concurrently with them.

This is a pattern I can absolutely relate with from experience. Some of my best classes where I learn the most are the ones where there are a few peers above my level to help me learn what they already have. Sometimes, the way someone explains something to you is difficult to make sense of, but another peer can explain it in a way that makes more sense and is easier to understand. Similarly, working with many people above your level gives you a wide variety of different methodologies and ways of doing things, which can help illuminate best practices and start insightful conversations.

The alternative, being the smartest person in the room, can be very unchallenging and doesn’t give you any room for development. It is nice to Share What You Know, but if that is all your doing it can be hard to progress your personal goals. A large disparity in the skill level of developers causes more time to be spent on closing that gap rather than working on the project at hand.

The challenge with this pattern is more the emotional toll it can take on you to be surrounded by smarter people. Being the dumbest person in the room can be beneficial from a self-centered learning perspective, however it can definitely feel a little embarrassing to be so far behind everyone else. Being able to swallow your pride for the development of yourself and the team is a challenge, but the rewards are worth it.

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.

After finishing our final project I was still curious on many things about angular and how we would use it in future projects if we were to transition over to becoming a front end developer. This blog ‘Why should you learn Angular in 2018?’ by Aman Goel talks about Angular is, the different types, and the advantages.

From what I’ve learned, Angular is a framework that developers use to build applications (a simplified view). Goel talks about the development of angular applications and how it incorporates Typescript along with HTML and CSS. I know I built my project with the latest version of angular when I created it with the @angular-cli/@latest command but apparently there are versions from Angular 1 to Angular 7 and skipping Angular 3.

Some advantages of using Angular is that it supports Single Page Applications which is what we did for our project. A single HTML page that is updated dynamically according to the interaction of the user.

He lists the advantages of using Angular as seen down below:

– Supports Single Page Applications
– Two-way data binding
– Modularity in Angular
– Reduced coding
– Declarative User Interface
– Easy Integration
– Cross Platform

Before reading this blog I did not know how much we learned from doing this project but after reading it, I realized that all of the advantages listed in this blog were used in the process.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

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.

In the final exam, there were a few questions on mutation testing which I was very unfamiliar with so I decided to look into posts/blogs about mutation testing. One interesting blog I came across was written by James White – ‘Mutation Testing – Who will test the tests themselves?’.

The very first sentenced stated “this is aimed at people who are not familiar with mutation testing” and it was all over from there; I had been sucked into the article since I had no idea what mutation testing really was.

White starts off by describing what mutation testing really is and his definition was “Very simply mutation testing is a way of testing the quality of your tests by introducing changes into your code and seeing if your test suite detects them”. Very straight forward. He then gives an example written in java and a scenario seen below:

private static final int MARGARINE_WEIGHT = 100;
private static final int COCOA_WEIGHT = 25;
private static final int EGG_COUNT = 2;
private static final int ORANGE_JUICE_VOLUME = 15;

Cake createCake(CakeType cakeType) {
Cake cake = new Cake();
cake.setMargarine(MARGARINE_WEIGHT);
cake.setSugar(MARGARINE_WEIGHT);
cake.setEggs(EGG_COUNT);
if (CakeType.CHOCOLATE.equals(cakeType)) {
cake.setFlour(MARGARINE_WEIGHT - COCOA_WEIGHT);
cake.setCocoa(COCOA_WEIGHT);
} else {
cake.setFlour(MARGARINE_WEIGHT);
if (CakeType.ORANGE.equals(cakeType)) {
cake.setOrangeJuice(ORANGE_JUICE_VOLUME);
}
}
return cake;
}

As well as different test cases:

@Test
public void canCreateVictoriaSponge() {
Cake actual = testee.createCake(CakeType.VICTORIA_SPONGE);
assertEquals(100, actual.getMargarine());
assertEquals(100, actual.getFlour());
assertEquals(100, actual.getSugar());
assertEquals(2, actual.getEggs());
assertEquals(0, actual.getOrangeJuice());
}

@Test
public void canCreateOrangeCake() {
Cake actual = testee.createCake(CakeType.ORANGE);
assertEquals(100, actual.getMargarine());
assertEquals(100, actual.getFlour());
assertEquals(100, actual.getSugar());
assertEquals(2, actual.getEggs());
assertEquals(15, actual.getOrangeJuice());
}

He then shows us the results of his tests as well as his mutation tests. So I learned that mutation testing works on the principle that since the test code is there to ensure that the code works, if mutating a test, at least one test should fail. Mutation killed means all your tests pass and mutation survived indicates that the mutation survived and there is a potential area where a bug could arise.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

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.

As I take my first step towards my journey in Software Quality Assurance and Testing I dive into Unit Testing. After searching the web found a really good podcast named “Unit Testing With Test Driven Development” by Beej Burns this podcast is about Unit Testing and focuses most on Test-Driven Development (TDD). I will be using this podcast to help me write this blog.

In the podcast they had two guess John and Clayton. They went on the podcast and talked about their book ‘Practical Test-Driven Development Using C# 7: Unleash the power of TDD by implementing real world example under .NET environment and JavaScript’. I personally have not read this book. According to the podcast this book is meant for Software Developers with a basic knowledge of TDD. This book is intended for those who wish to understand the benefit of TDD. This book is beneficial for individual who know C# basic since all the examples are in C#.

The Following Q&A are the Question asked in the podcast and the guest answer. The answer I am writing are summarized in my own words but originally derived from the guest on the podcast. Also I am not doing all the Q&A just the ones I found interesting and liked how the guest answer the question. If you want to hear the original question and answer visit the podcast site: https://completedeveloperpodcast.com/episode-140/, Lets start.

What is Unit Testing?

Unit Testing is the ability to test in isolation. That is to simply test an application without affecting the rest of the other test.

Why is Unit Testing important?

We use unit testing to make sure each unit performs as intended. Unit testing is important because it minimizes the risk of error in your software, but it also forces you to have better code structure. It also allows major changes in your code to happen at a lower risk. Another reason it is important is because it allows new developer to understand your software structure.

*Note that naming convention is very important so developers can understand what is being tested.*

What is the point of Test-Driven Development (TDD)?

The point of TDD is doing the right thing without making a mess. That is short iteration cycle reassuring that you and your application are doing the right thing.

According to one of the guests when writing Test-Driven Development there are 3 stages/steps:

• Red cycle to see test fail
• Green phase when you make the test pass
• Refactor production code and test code.

The idea of TDD is to build the test before the code.

Other benefit for TDD other than code in an organized level is:

• Reduces the overall bugs and make bug resolution quicker.
• Less down time.
• Better requirement
• Can find problems with just running the test which it shows where code went wrong.

What are some of the things people get wrong about unit testing and TDD?

Testing your test too close to your implementation. “Test should represent the business rules not how you decided to implement the business rule. That way when you go and change stuff later on like the implementation. You want to refactor and remove thing into a different class. This doesn’t break what your test does because you will be restructuring how it is doing it”.

How do you manage complexity on a unit test, and how do you structure your overall testing projects?

“Form an overall method uncle bob (Robert Martin) suggest only having method that are five lines or less in size”. The guest that answer this question take Robert Martin suggestion to heart. He goes on and explains that if a method has more then five lines then he’ll brake it down into more than one method. If a class has more than five method then he’ll brake that down into more than one class. If a folder has more then five class than he’ll brake that down into more than one folder. If a project has more then five folder he’ll consider braking it down into more than one project. He goes on and say that he will do the same exact thing when testing except he doesn’t care much about the line length because most test case are usually 3-4 lines long. He has the arrangement where he set up the pre-content of the test and then have the action are 1-2 lines. These tests are pretty small to start with but within a test class he won’t have more than five things overall that he is testing within a test class, no more then five unit, and no more than five logical assertion which tends to reduces the size of any one thing within a test project.

What are some good practices you can use to make sure your test is maintainable on the long run?

• “Don’t forget to refactor your test, because your test suit is just as important as your production code”.
• “Remember you are testing small unit or small pieces that should have never enter connective dependency so that you feel comfortable substituting a mock, spy, or fake implementation. Be careful not to test your fake, mock, or spy.”
• “Where ever the code end that’s where the test should end”.
• “Make sure we abstract all third-party code”.

I will wrap this up by saying unit testing is a very important skill to have no matter what. It helps in creating clean code and reduces the risk of error. Unit testing allows software developers to make large changes in the software code at a minimal risk rate and it allows code structure to be understandable by new developers. One thing to note is when creating unit test and developing software you must make sure to have good naming convention. When developing software, its best to start with writing the test first.

My name is Yesenia Mercedes-Nunez and this has been YessyMer in the World Of Computer Science, thank you for your time until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

In the second part of Brandon Gregory’s blog post “Coding with Clarity: Part II“, he starts with the assertion that “Good programmers write code that humans can understand”. In the spirit of clarity, Gregory continues to elaborate on solid design principles that are helpful in software engineering.

The first principle is the Law of Demeter, or as Gregory puts it “the principle of least knowledge”, and describes this principle as an application of loose coupling, another design strategy that states one part of a program should not rely on others. Adhering to this principle will help ensure flexibility if new features are added or modified.

An example Gregory uses that demonstrates this principle is the use of getter/setter methods to provide access to class data as opposed to allowing classes to directly access data. By applying this tactic, it ensures that future modifications do not mess up any other parts of your program, as all modifications will be in the getter/setter methods.

The next programming practice is the Interface Segregation Principle. This is to make sure no object contains methods it doesn’t use. If a class has a bunch of methods, and not all methods are used for each instance, the better strategy is to separate that class into specific interfaces or sub classes. This is a similar goal as the strategy design pattern that we discussed in class.

However, Gregory warns us that abstraction can be taken too far. It is possible to abstract so much that the program contains an excessive number of interfaces or sub classes. The author reminds us that the goal of abstraction is to reduce complexity.

The final principle in the article is the open/closed principle. This assertion is that software should be open for extension but closed for modification. If the program is designed correctly, the implementation should perform as specified and should not be modified. Instead, to change functionality of the program, all that should be done is adding functionality, and not changing any of the existing code.

I very much found this two part series of “coding with clarity” helpful.  Almost all of the principles Gregory explains have been applicable to content we have covered in class. I found his writing style easy to follow and the particular examples he uses to demonstrate the principles are cogent and illuminating.  I recommend them to everybody looking to improve their design knowledge.

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

Blogger Lukas Rosenstock posting for the company website BlazeMeter describes common API test strategies and definitions in his post “API Performance Testing Scenarios and Vocabulary“. While a good portion of the post examines how this particular software can help with this type of software testing, the general strategies and explanations he gives are definitely helpful in identifying meaningful test suites.

Rosenstock first describes Application Program Interface or API testing by defining the two main paradigms: Functional tests and Load tests.

Functional tests, aim to verify that the software functions perform as the specifications prescribes. Testing strategies such we learned in class such as equivalence class testing and boundary value testing can help us determine appropriate values to test in order to verify that the program behaves as expected.

Load tests on the other hand, test other real world complications that are out of the scope of functional testing. The main example Rosenstock goes into is the consistency and response time given an expected amount of user traffic. Load tests are generally functional tests that that are performed on many virtual users to simulate when the program performs in the real world.

From here on, the author describes the various types of load tests; what it is they are testing for and strategies for how to collect the information.

First, stress testing is the process of load testing where you start with a small number of virtual users and steadily increase the sample size and record specific performance times. This strategy gives information about performance at specific intervals.

Rosenstock also describes soak tests. The defining qualities of soak testing is to verify that memory efficiency is achieved. If there are any data leaks or unnecessary variables floating around in the software, and the maximum amount of memory is reached, the program can fail. So soak testing is the process of running load tests over a long period of time to determine that space efficiency is achieved.

I found this post helpful in illuminating even more situations that need to be tested for. While verifying the behavior specifications in a program is essential, there are also other real world situations that must be accounted for, such as the volume of user inputs. In this way, load testing is just as essential as functional testing, and this article definitely helped add to my understanding of the scope of good software testing.

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