I am writing in response to the blog post at https://www.guru99.com/full-stack-developer.html titled “What is Full Stack Developer? Skills to become a Web Developer”. A full stack developer is somebody who is able to work in both front end and back end development. We have worked with back end development in CS 343 with our work in REST APIs, and we have also worked with front end development using Angular JS and TypeScript. Full stack development involves writing both ends.

The blog post describes a full-stack web developer as somebody who can work on both the front end and the back end of an application. It provides a tiered model of application layers that the developer should be familiar with: the presentation layer, business logic layer and database layer. We have briefly discussed the concept of a layered application model in class before. The presentation layer is the front end that handles the user interface, and the business logic layer and database layer correspond to the back end.

Some average income statistics are provided in the blog post, which shows that a “back end developer” earns more on average than a “full stack developer”, which seems counter-intuitive because a full stack developer, in theory, is capable of accomplishing the same tasks as a back end developer and more.

A clarification is made about the expected duties of a full stack developer; a supposed myth is that a full stack developer is going to be writing all of the code by themselves, writing both the front end and back end for a single large application because both jobs are within their skill set. In actuality, it is not the job of a full stack developer to produce everything alone. The blog post describes a full stack developer as a sort of a bridge between front end developers and back end developers who are working on the same project, because the full stack developer has a good perspective of both ends and how they interact with each other. In this sense, it is clear that a full stack developer in a development team is particularly beneficial for communication.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

In this week’s blog, I will be talking about Integration Testing from Software Testing Fundamentals.

The International Software Testing Qualifications Board definition:  Integration Testing is a test performed to expose defects in the interfaces and in the interactions between integrated components or systems.

Integration testing is a level of testing where units are tested as a group making sure they all work when put together. It is performed after Unit Testing and before System Testing. Developer themselves or independent testers are responsible for performing Integration Testing. There are different kind of approaches to Integration Testing:

• Big Bang is an approach where all or most of the units are combined together to be tested in one go when the testing team receives the entire software bundle. Kind of like System Testing but it only tests the interactions between units and not the entire system.
• Top Down is an approach where top-level units are tested first before the lower level ones.  This approach is taken when the development of the software was also from top to bottom.
• Bottom Up it is basically like Top Down instead you go from the bottom to the top.
• Sandwich/Hybrid is a combination of Top Down and Bottom Up.

I picked to read this blog because it offers useful analogies to make it easier to understand. There was also a gif at the bottom of the blog where it shows what happens when you do not do an Integration Testing. There were also tips on how to do Integration Testing properly. One of them was to “ensure that you have a proper Detail Design document where interactions between each unit are clearly defined. In fact, you will not be able to perform Integration Testing without this information.” I think that was pretty much the main point of that you have to take from Integration Testing. That you need to know how the system works or the design of it, else Integration Testing would not make any sense to do. Another take on from this blog is to make sure that every unit is unit tested before you start Integration Testing.

Lack of Integration Gif:

https://giphy.com/embed/3o7rbPDRHIHwbmcOByvia GIPHY

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

I am writing in response to the blog post at https://www.guru99.com/what-is-backend-developer.html titled “What is Backend Developer? Skills to become a Web Developer”. We have begun learning about backend development in the CS 343 Software Construction, Design and Architecture class by studying REST APIs using TypeScript and Angular JS. The blog post gives a general description of backend development and some career-related information like skillsets and average salaries.

Backend development is about defining the behavior and structure of a backend server and/or database. As opposed to the front-end, the backend is not visible to a visitor of a website or application or user of a service. One primary part of the backend may involve a database, where information is stored and retrieved to present to a user. The other primary component of a backend is the server, which is the machine that runs code and handles functionality. APIs are also part of backend development, which are interfaces designed for the purpose of enabling a front-end to communicate with the server.

A backend developer is an individual who creates and maintains the backend. The blog post goes into some detail about what a backend developer is generally expected to do, what their goal is, and also how much they tend to get paid. According to the blog post, back-end developers get paid more than front-end developers. Backend developers tend to the database, server and API for the purpose of supporting the front-end.

One particularly interesting distinction between a back-end and a front-end is that a back-end can be developed independently of a front-end, but a front-end cannot be developed independently of a back-end. It is possible to simply design a back-end for no intended application, and then afterwards build the application around the existing back-end service.

This article is a good summary of what backend development is about and what a backend developer does, and the difference between a front-end developer and a backend developer. Aside from the database management related components of backend development, the given description of backend development is consistent with what it is we are dealing with in class.

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

I am writing in response to the blog post/tutorial at https://www.guru99.com/domain-testing.html titled “What is Domain Testing in Software Testing? (with Example)”. It goes into some detail describing what domain testing is, which is a topic that we have already seen in the CS 443 Software Quality Assurance and Testing class. Domain testing is a type of functional testing, which is a quality assurance process for testing whether the functionality of a system is behaving properly by verifying that certain inputs correspond to the specified outputs.

One thing about the blog post I am not quite certain about is that it refers to domain testing as an important “white box testing method”, which seems inaccurate; the act of checking inputs against expected outputs is independent from the software’s inner workings. Feeding the program an input and checking that the output is correct is a black box testing approach. The clarity provided by a white box would however be necessary in defining the specification itself, methods such as boundary value testing or equivalence class testing require equivalence classes and boundaries to be identified, which would require access to the inner machinations of the software.

Equivalence class testing and boundary value testing are a primary focus of the blog post. Equivalence class testing partitions the set of possible inputs into subsets of inputs that have the same behavior, and boundary value testing tests the behavior given inputs at the boundaries of equivalence classes. The boundary values are particularly useful inputs to test because they are edge cases that are more likely to produce incorrect results compared to arbitrary values chosen within the boundary. If there is an off-by-one logical error then testing the boundaries is what will make it apparent.

I think that this blog post is a good summary of some of the testing methods we have learned about in our classroom activities. It does not go into as much detail or cover more specific varieties of testing such as weak and strong or robust boundary value testing, but it is a short and simple introduction to what domain testing in software testing is about.

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

Over the past few months, I’ve been asked the same general question about Angular multiple times in onsite training classes, while helping customers with their architecture, or when talking with company leaders about the direction web technologies are heading. After hearing that general question over and over I decided it was time to put together a post … Continue reading Some benefits of Angular and Typescript! →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

An important thing to consider for software testing is the difference between unit testing and integration testing. The purpose of a unit test in software engineering is to verify the behavior of a relatively small piece of software, independently from other parts. Unit tests are narrow in scope, and allow us to cover all cases, … Continue reading Unit Test vs. Integration Test →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

This blog https://effectivesoftwaredesign.com/2010/12/22/identifying-anti-patterns/ titled “Identifying Anti-Patterns” discusses what it refers to “anti-patterns”, a category of common code practices that resemble the organizational structure provided by the use of design patterns, but are actually counterproductive and not a good design. I think that the existence of anti-patterns is interesting; in an effort to write code that is well structured and easy to follow, it is actually made worse. The blog post points out that anti-patterns are most commonly used by programmers who are inexperienced and end up writing code with bad design and bad performance, but it is also possible for experienced programmers to do well in implementing a good design, but at the cost of a significant sacrifice on performance. In general I think it would be common for the implementation of a design pattern to have some performance trade-off with readability and maintainability, so there must be some line as to where a design pattern would become an “anti-pattern” if it were to cause some level of a decrease in performance. Design patterns are commonly used for the sake of scalability so that a program with a well-structured foundation will be easier to maintain as it becomes larger, but these design patterns that are implemented during the beginning of the development of the program may seem like unnecessary anti-patterns that are unnecessarily abstract for the current scope of the program. It may be difficult to identify anti-patterns given that excuses and arguments can be made for why code should be implemented in a certain way. Over-complicating things has an impact on performance, but an organized foundation is well suited for a large project, and re-implementing a lot of code as a project grows would likely be more counterproductive than being careful from the beginning. There definitely are some practices that are objectively wrong, but this blog post does not go into any examples, and it is also possible that what may be identified as an anti-pattern could be a false positive. When there is a trade-off between design and performance, it makes the most sense for an anti-pattern to refer to a mistake that is ineffective in both areas.

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

In this blog post https://medium.com/engineering-housing/nan-is-not-equal-to-nan-771321379694 “NaN is not equal to NaN!”, Dron Rathore discusses the IEEE standard of NaN being a value which is not equal to itself. The blog explains some of the definitions and implementations surrounding NaN. It is not an opinionated blog post, it is mainly for the sake of being an educational resource. My particular interest is the actual reason in the first place for why NaN is defined as not being equal to itself. The result of comparison must be a boolean, so the only options for trying to compare NaN to itself are to return true or false, or error and crash. In mathematics, NaN is effectively “undefined” or “indeterminate”, so something like 0/0 is undefined. The truth value of the equation 0/0 = 0/0 is also undefined; the operation of equality is not defined for values that are not defined themselves unless the operation itself is given additional definition to account for that case, which is what must be done for programming languages so that it results in a boolean value. The choice for that value to be false is peculiar and ultimately seems arbitrary, but it is useful for detecting values that are NaN; if (x == x) is false then x is NaN. This blog post does not directly give any feedback on the reason for this implementation of NaN, it merely describes it, but I would like to get some perspective on how the choice is made and how it is more logical to have NaN not equal to itself over an alternative implementation where it is. Comparisons involving NaN may still result in confusing outputs; infinity > NaN is false, for instance, and so is infinity <= NaN, but “not (infinity <= NaN)” is true. For the sake of software testing, NaN adds a lot of strange edge cases where assumptions about equality lead to contradictions. In these cases, or in any case where it is not okay for NaN to exist, it makes the most sense to just have errors instead of trying to deal with this unique behavior.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Between many design patterns Mediator is one of most used in today’s software world. In this pattern, the object encapsulates the processes between other objects, without asking other objects to interfere. We are going to analyze a real-world example that uses the mediator design pattern. This pattern serves as a go-between operator, so other components … Continue reading Mediator Pattern →

From the blog cs-wsu – Kristi Pina&#039;s Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

This week’s blog is going to be about “The challenges and benefits of model-based testing” by Greg Sypolt.  In this blog, Greg talked about what model-based testing(MBT) is, how it works, how model-based testing differ from other kinds of testing, the challenges that are faced when using model-based testing, and the benefits of using it. Model-based testing is a kind of test where test cases are automatically generated from models. It focuses on the models based on the system requirements or specifications. The model-based testing works by generating tests automatically from models created by the software developers and testers, then it runs assertions for both generation of tests and execution, and reports the testing results. Model-based testing is different because it is more in the software development process than a scripting task. It focuses more on building a testable application and creating models based on user’s perspectives.  There are many challenges to address before you can use model-based testing to its full benefits. Software developers and testers have to be trained on model-based testing. The tool has to be scalable and be able to handle complex models and provide a reliable test coverage. Fine-tuning the MBT tool could also be challenging. However, it will offset the long-term goal of reduction of test maintenance. Test coverage is guaranteed and there is zero test suite maintenance.

I think this blog post is very helpful in introducing model-based testing. It is fairly brief but still shows you the idea behind model-based testing. This blog post is really interesting since model-based testing is a move away from the traditional testing. Instead of having a set of particular tests with defined test objectives and deliverables that should be achieved, model-based testing is done from models and not from the source code. A thought-provoking section of the blog for me is where he talked about the challenges of model-based testing. Greg said that model-based testing requires a shift in mindset and culture in how to develop and test applications. It made me think of how different it really is from the traditional way of testing. Learning about model-based testing changed the way I think about software testing since it is an approach that I haven’t really seen before. Now, I wonder in the future, what else kind of testing we are going to come up with.

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