Flaky tests are tests that could pass or fail for the same code. This is a problem because the failure of a flaky test doesn’t always indicate a problem with the code, but you can’t just ignore the test because you could be ignoring a bug.

In the the blog post “Where do our flaky tests come from?”, Jeff Listfield, a Senior Software Engineer at Google, talks about the the potential causes of flaky tests and what can be done to avoid creating flaky tests. He demonstrates the correlation between the objective size of the test (binary size, memory usage) and the likelihood for it to be flaky. He also shows a correlation between certain tools and a higher rate of flaky tests, however, the reason for this is because larger tests are more commonly written using those tools. The tools themselves only contribute a small amount to the likelihood of a flaky test being created. When writing tests you should think about what code that you are testing and what a minimal test would look like in order to minimize the likelihood of creating a flaky test.

I chose this topic because effective use of test cases is very important in software development because it allows you to make sure that you’ve addressed and tested all of the product requirements, allows future testers to run your test cases when needed, and also makes it possible to build automated scripts to run as many tests as possible. By writing your test cases out, you also won’t need to constantly repeat the process and remember what values you’re testing every time as they’ll already contain all necessary variables, allowing you to maintain consistency in your tests.

This blog post in particular was interesting because it uses data gathered from real tests used in Google’s continuous integration system to show a cause of flaky tests and how to avoid them. Before reading this blog I didn’t realize how important writing test cases really was, but seeing just how many automated tests that Google used (4.2 million!) which lead to me doing more research on their importance. It also reminded me that the best solution is usually the simplest, in that you should remember to keep your test cases as simple as possible to avoid creating a flaky test and giving you a headache in the future trying to figure out what’s wrong.

Source: https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html

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

Flaky tests are tests that could pass or fail for the same code. This is a problem because the failure of a flaky test doesn’t always indicate a problem with the code, but you can’t just ignore the test because you could be ignoring a bug.

In the the blog post “Where do our flaky tests come from?”, Jeff Listfield, a Senior Software Engineer at Google, talks about the the potential causes of flaky tests and what can be done to avoid creating flaky tests. He demonstrates the correlation between the objective size of the test (binary size, memory usage) and the likelihood for it to be flaky. He also shows a correlation between certain tools and a higher rate of flaky tests, however, the reason for this is because larger tests are more commonly written using those tools. The tools themselves only contribute a small amount to the likelihood of a flaky test being created. When writing tests you should think about what code that you are testing and what a minimal test would look like in order to minimize the likelihood of creating a flaky test.

I chose this topic because effective use of test cases is very important in software development because it allows you to make sure that you’ve addressed and tested all of the product requirements, allows future testers to run your test cases when needed, and also makes it possible to build automated scripts to run as many tests as possible. By writing your test cases out, you also won’t need to constantly repeat the process and remember what values you’re testing every time as they’ll already contain all necessary variables, allowing you to maintain consistency in your tests.

This blog post in particular was interesting because it uses data gathered from real tests used in Google’s continuous integration system to show a cause of flaky tests and how to avoid them. Before reading this blog I didn’t realize how important writing test cases really was, but seeing just how many automated tests that Google used (4.2 million!) which lead to me doing more research on their importance. It also reminded me that the best solution is usually the simplest, in that you should remember to keep your test cases as simple as possible to avoid creating a flaky test and giving you a headache in the future trying to figure out what’s wrong.

Source: https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html

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

Flaky tests are tests that could pass or fail for the same code. This is a problem because the failure of a flaky test doesn’t always indicate a problem with the code, but you can’t just ignore the test because you could be ignoring a bug.

In the the blog post “Where do our flaky tests come from?”, Jeff Listfield, a Senior Software Engineer at Google, talks about the the potential causes of flaky tests and what can be done to avoid creating flaky tests. He demonstrates the correlation between the objective size of the test (binary size, memory usage) and the likelihood for it to be flaky. He also shows a correlation between certain tools and a higher rate of flaky tests, however, the reason for this is because larger tests are more commonly written using those tools. The tools themselves only contribute a small amount to the likelihood of a flaky test being created. When writing tests you should think about what code that you are testing and what a minimal test would look like in order to minimize the likelihood of creating a flaky test.

I chose this topic because effective use of test cases is very important in software development because it allows you to make sure that you’ve addressed and tested all of the product requirements, allows future testers to run your test cases when needed, and also makes it possible to build automated scripts to run as many tests as possible. By writing your test cases out, you also won’t need to constantly repeat the process and remember what values you’re testing every time as they’ll already contain all necessary variables, allowing you to maintain consistency in your tests.

This blog post in particular was interesting because it uses data gathered from real tests used in Google’s continuous integration system to show a cause of flaky tests and how to avoid them. Before reading this blog I didn’t realize how important writing test cases really was, but seeing just how many automated tests that Google used (4.2 million!) which lead to me doing more research on their importance. It also reminded me that the best solution is usually the simplest, in that you should remember to keep your test cases as simple as possible to avoid creating a flaky test and giving you a headache in the future trying to figure out what’s wrong.

Source: https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html

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

The Observer pattern is very commonly used and is one of the Gang of Four design patterns which are meant to solve design problems and create reusable object-oriented software.

The book chapter from the book Game Programming Patterns by Robert Nystrom on the Observer pattern provides an example of its use in specifically game design (an achievement system), however its implementation remains the same as it would in any other type of software. The pattern essentially allows communication between systems without having to couple them together. It does this by creating observers that receive notifications from the subjects that their observing and sharing that information.

In the example provided by the chapter, it shows how a physics system can communicate to an achievement system to unlock an achievement where the player falls off a bridge:

It does this without having to couple the two systems together and eventually creating a huge mess of code.

The author then goes on to describe some concerns and potential problems of using the patterns, such as speed and memory allocation, as well as their solutions. Although even if you implement this or any design pattern correctly and efficiently, it doesn’t mean that it’ll work well depending on whether or not it’s applied on the right problem.

I chose this chapter in particular because it’s likely that we will be using this pattern in the future. Also I think it’s interesting to see how these design patterns can be used in game development, so it may be useful to others who are interested in developing games. I used this pattern in the past for a system where the physics system would notify the observer when a collision happened and it would tell the sound system to play the sound for that collision. I ended up running into a lot of problems due to my poor implementation of the pattern, getting errors because of improper memory allocation. Referencing the examples from this chapter helped me learn how to fix these issues and optimize my code. However, while using the Observer pattern for my audio system worked properly, I ended up doing it differently afterwards using a service locator to provide a global point of access to the audio system as well as an event queue to prevent multiple instances of the same sound from playing at once and blowing out my ears. Although I wouldn’t use the Observer pattern in this situation again, it’ll probably be useful in the future.

Source: http://gameprogrammingpatterns.com/observer.html

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

The Observer pattern is very commonly used and is one of the Gang of Four design patterns which are meant to solve design problems and create reusable object-oriented software.

The book chapter from the book Game Programming Patterns by Robert Nystrom on the Observer pattern provides an example of its use in specifically game design (an achievement system), however its implementation remains the same as it would in any other type of software. The pattern essentially allows communication between systems without having to couple them together. It does this by creating observers that receive notifications from the subjects that their observing and sharing that information.

In the example provided by the chapter, it shows how a physics system can communicate to an achievement system to unlock an achievement where the player falls off a bridge:

It does this without having to couple the two systems together and eventually creating a huge mess of code.

The author then goes on to describe some concerns and potential problems of using the patterns, such as speed and memory allocation, as well as their solutions. Although even if you implement this or any design pattern correctly and efficiently, it doesn’t mean that it’ll work well depending on whether or not it’s applied on the right problem.

I chose this chapter in particular because it’s likely that we will be using this pattern in the future. Also I think it’s interesting to see how these design patterns can be used in game development, so it may be useful to others who are interested in developing games. I used this pattern in the past for a system where the physics system would notify the observer when a collision happened and it would tell the sound system to play the sound for that collision. I ended up running into a lot of problems due to my poor implementation of the pattern, getting errors because of improper memory allocation. Referencing the examples from this chapter helped me learn how to fix these issues and optimize my code. However, while using the Observer pattern for my audio system worked properly, I ended up doing it differently afterwards using a service locator to provide a global point of access to the audio system as well as an event queue to prevent multiple instances of the same sound from playing at once and blowing out my ears. Although I wouldn’t use the Observer pattern in this situation again, it’ll probably be useful in the future.

Source: http://gameprogrammingpatterns.com/observer.html

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