Keller Liptrap
Week 2
SE1
Summary
The first section of the Software Engineering book is talking about how we can think about software engineering and some things that go with it. The authors of the book say that software engineering is not just the act of coding and writing code but it is the act of maintaing code over time. There are three key time and change, scale and growth, trade offs and costs. Then the perspectives of google is discussed. They have three aspect of google engineering which are culture, process, and tools. In further chapters these will be gone into further detail.
Reflection
I found this begging section of the book ingresting. Ive always thought of sofware engineering in a more black and white way but in this section the authors provide different ways in which we can think about sofware engineering. I also think that the insite of googles philosiphy of software engineering is useful in creating our own code for our upcoming software development task.
Use-Case
A key point that will stick with me from this part of the book is that software developement is maintaining code overtime. Keeping this mind set throughtout the semster working on chasten. This mindset may help with the idea of getting it all done at once rather its a task by task software development over time.
FB1
Summary
The first chapter in FB is introducing the world of software testing. This chapter descirbes the importance of testing your coding for software development. Testing your software can help with bugs, the overall quality of the code, and how reliable your software is. Althought testing is a great tool for software developers it has its limitations. These testing dont gurantee your code to be bug free or to work as intended.
Reflection
Learning about testing sofware is important. Testing software is key to the code working as intended and being bug free. Learning about test for sofware will ultimatley help use as softare engineers but it is important to keep in mind that developing and running test on our code is not full proof and may not pick up on some errors that we made.
Use-Case
In the case of Chasten and our overall projects as a software start up class sofware testing will be a crucial part to our success. Making test cases for our software will be important to ensureing our code is good to ship and will not break once shipped.
Week 3
SE2
Summary
In this section of the Software Engineering book we are looking at what is software engineering. First they describe three difference in just regular programming copared to software engineering such as time, scale, and the trade-offs at play. In this section of the book the author speaks about again the idea of software being a program over time. At google they think about the life span of a software project when working on it. From this idea a few more ideas or questions come off of it such as how does time effect this code or will the developers need to change the code more often. One thing that stood out to me is Hyrum’s Law which states If you are maintaining a project that is used by other engineers, the most important lesson about “it works” versus “it is maintainable”.
Reflection
Overall I enjoyed the second section of the Software Engineering book. The more in depth look at how software is looked at over time and how it can be maintained. I find the relationship between time and change within a sofware engineering to be intresting and beneficial when thinking about how to program.
Use-Case
While working on chasten I beleive we can incoperate some of the questions that google sofware engineers use when they are coding their software programs. This may make it easier to look at the big picture of the project we are working on.
FB2
Summary
In this section of FB we are talking about code coverage.In this section they are using the ‘Coverage’ class which allows us to see the coverage of our python code that we are running. Further on in the chapter we talk about black and white box testing. Black box testing is checking each piece of the function to see if it is equal to what we expect the out come. White box testing focuses more on the implementation of the program. It test mainly statement coverage and branch coverage Statment coverage is where each statement in the code must be executed by at least one test input and branch coverage is branch in the code must be taken by at least one test input.
Reflection
This section of FB is important. As we talked about in class test cases can be written in a way that is not beneficial for making sure your code or program will excute correctly on other computers or with a certain input. In the chapter talking about coverage and how this coverage check the code is important. Using a whote box appraoch of testing code coverage is beneficial in making sure your code is performing in the way you inteded it to be.
Use-Case
We can use the code coverage to our benefit when creating chasten. COde coverage will be key in checking our work and limiting issues. This may also help us find where there are bugs in our code based on tests and the coverage of the python code.
Week 4
SE3
Summary
In this chapter of Software Engineering we are focusing on how to work well in a team. They talk about a few ideas or concepts to help you the reader think about how to work well in a team. The author mentions Guido Van Rossum who wrote the first version of python but with out a groups of people and teams python would not be where it would be today. Another idea thta is talked about is hiding is harmful. The author brings up a point that keeping ideas and your thoughts to yourself might be hindering your preformance as a coder. Later in the reading it is also discussed being open to influence. Being vulerable in this sense allows you to be a better coder and learn more about what you are working on.
Reflection
I found this section of the Software Engineering book helpful and good insight into the mindset and how to work with a team of people. Like many in computer science 203 I have never worked with this larger of a group of people on a singular project. This section gives good ideas into what you should and should not do when working with a team. I personally found this very helpful.
Use-Case
As a team working on the chasten project we can take into account these ideas and mindsets when working as a team. Doing this can improve our productivity as a team and keep us on schedule for shipping our product.
FB3
Summary
In this chapter of the Fuzzing Book we are talking about fuzzing tests and their creation along with the applications of them and how these test hold up to other types of tests. The fuzzer or fuzzing test will create a large amount of inpputs that can be input into a function or program. This is used to see if the program can handle a large input that may break the program. Throughout the chapter the length of these randomly generated inputs get larger. Further on in the chapter checks and the use of the fuzzer is introduced. The combination of these can help improve a program. The checks can serve as security for the program to begin with.
Reflection
The purpose of this chapter is to look at weak points in a program. They do this in this chapter by using large inputs. Using the fuzzer and checks can help you identify these weak points and make your code better.
Week 5
SE4
Summary
In SE4 we are talking about knowledge sharing. To begin the author explains the challenges of learning that ultimatley links into the knowledge of sharing with others. Theres a few bullet points that stuck out to me in this section. The first one is “Lack of psychological safety” which is an enviroment where people are afreaid to be wrong and make mistakes due to them thinking they will be punished for it. The second point that stood out to me is the “All-or-nothing expertise” where there is two sides of expertise and not much middle ground in knowledge. The people who have all the knowledge continue to gain it and those we have little knowledge are left behind. Throught out the reading they reinforce on the ideas given earlier in the reading. Creating an enviroment that promotes knowledge being shared so others can help eachother is important to wokring as a team.
Reflection
Overall I think this article speaks very well to how a class needs to work and discuss knowledge for their first time working in a large group. I believe it is important to have safe spot to discuss ideas and thoughts on the project without fear of being wrong. Another key detail is the all or nothing expertise. Its important to not leave behind the people in the class who may not have as much knowledge of others.
Use-Case
I believe all of these ideas can be applied into our classroom for working as a group. Many if not all of the students in the class have not worked in a group this large of a group and can cause some to be uncomfortable in sharing ideas.
FB4
Summary
In this chapter of FB we are looking at mutation analysis. Using mutation analysis is a different way of testing your code for bugs and issues. By putting in mutations or artificial faults into your code test suites are made to see if these mutations can be detected.
The first section of code we use creates a mutation analyzer function:
class MuFunctionAnalyzer:
def __init__(self, fn, log=False):
self.fn = fn
self.name = fn.__name__
src = inspect.getsource(fn)
self.ast = ast.parse(src)
self.src = ast.unparse(self.ast) # normalize
self.mutator = self.mutator_object()
self.nmutations = self.get_mutation_count()
self.un_detected = set()
self.mutants = []
self.log = log
def mutator_object(self, locations=None):
return StmtDeletionMutator(locations)
def register(self, m):
self.mutants.append(m)
def finish(self):
passThis is used in combination of a previously made function that deals with types of triangles:
def triangle(a, b, c):
if a == b:
if b == c:
return 'Equilateral'
else:
return 'Isosceles'
else:
if b == c:
return "Isosceles"
else:
if a == c:
return "Isosceles"
else:
return "Scalene"To add mutations we use this function:
class Mutator(ast.NodeTransformer):
def __init__(self, mutate_location=-1):
self.count = 0
self.mutate_location = mutate_location
def mutable_visit(self, node):
self.count += 1 # statements start at line no 1
if self.count == self.mutate_location:
return self.mutation_visit(node)
return self.generic_visit(node)Reflection
In this chapter of fuzzing book the use of mutation analysis of code. Before reading this I had not heard of this term or idea. I think that nutation analysis is an intresting conceept since it creates inputs as mutations to the function to see how they react and the production of the code. I believe that this is an intresting alternative to specific test cases but I am not sure which one is the best way to test your code.
Use-Case
In chasten we have test cases to check our code coverage and to make sure there are no bugs in the code. The implimentation of mutation analysis might be intresting. Similar to the fuzzer idea it creates a random mutation for the code which might help us simulate a user.
Week 7
SE5
Summary
In this chapter the software engineering book at google the author is talking about how software can meet the needs of as many people as possible. The author talks about where google has come up short when trying to achieve getting their software to as many people as possible. The example they gave is the use of facial recognition where some bias may have been used in the creation of the software they may not expand to all people. There are a couple of steps that someone or a group of people can take to maximize the audience. Who Who are the people building the product? Do these people represent those for whom the product is being built?
Reflection
Its important to have a welcoming and inclusive enviroment when working in a group of any type of software project. This chapter describes how we can have an inclusive work enviroment as well as inclusive software that other can use. Ethical concerns have always been prevelant when coding and sofware engineering and I believe that this chapter addresses ways that we can consider some ethical issues.
Use-Case
In the case of chasten we are creating this tool to improve upon life as a computer science student. Knowing our targeted audience and who we need to reach when creating this tool allows us to correctly assess the tools ability to reach others. This is important to keep in mind when creating the tool. Also the use of inclusivity and ethics are important to keep in mind when discussing and writing code for the project.
FB5
Summary
In this chapter of Fuzzing Book we are talking about mutation analysis. Mutation analysis is the implimentation of mutations within ones code. This can be as simple as changing an operator sign or as large as removing a for or a while loop. In combination of this using test suites to test your code after using these mutations allow you to see how well the test suites are working when looking at your code.
class TestGCD(unittest.TestCase):
>>> def test_simple(self):
>>> assert cfg.gcd(1, 0) == 1
>>>
>>> def test_mirror(self):
>>> assert cfg.gcd(0, 1) == 1
>>> for mutant in MuProgramAnalyzer('gcd', gcd_src):
>>> mutant[test_module].runTest('TestGCD')
>>> mutant.pm.score()
======================================================================
FAIL: test_simple (__main__.TestGCD)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/var/folders/n2/xd9445p97rb3xh7m1dfx8_4h0006ts/T/ipykernel_78662/2565918356.py", line 3, in test_simple
assert cfg.gcd(1, 0) == 1
AssertionErrorReflection
I think that mutation analysis and the use of mutations are very important when testing code or software. Simple changes of changing an operator can cause a whole program to not work as intended so it is important to test these and have test suites to check for these small mutations. One large issue would be removing a loop and test suites not picking it up which is another reason why mutation analysis is important.
Use-case
We can use mutation analysis when testing our code for the chasten project. This can allow us to check the code and see if it runs properly with test suites. This may also help with code coverage.
Week 8
SE6
Summary
This section of the google engineering book is a all about leadership and being a leader in a team. The author describes how individuals take a leadership role within google and how they achieve these roles. Individuals that are transitionsing to these leadership roles have the influence but are not being authoritative. One of the intresting sayings from the chapter is being a leader protect your team from chaos. There are many concepts and ideas in this chapter about how to lead and manage a team.
Reflection
This chapter provides great insight into how to lead a team and how this is provided into the google software team. I think there are mnany concepts that are applicable to our class. I think the idea of shielding your team from chaos is intresting. Making sure your team stays on track and ingnoring the chaos can cause the team to be more productive.
Use Case
I think we can apply these concepts within our class. Since many of us have not had this kind of resposibility within a class room to take lead in a class. Applying these concepts of leadership could help our overall production and mesh as a team.
FB6
Summary
Grammers consist of symbols and rules that expand throught the symbol. For example digits:
<start> ::= <digit><digit>
<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9The digit “symbol” is then described by several integers that can be used.
This can also develope into more complex lanuage use for complex math problems and functions that can creates an equation:
<start> ::= <expr>
<expr> ::= <term> + <expr> | <term> - <expr> | <term>
<term> ::= <term> * <factor> | <term> / <factor> | <factor>
<factor> ::= +<factor> | -<factor> | (<expr>) | <integer> | <integer>.<integer>
<integer> ::= <digit><integer> | <digit>
<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9This can also be represented in more readable language and syntax that will allow individuals to build grammer based fuzzing function and use them in their projects.
import random
import re
from typing import Any, Callable, Dict, List, Set, Tuple
Grammar = Dict[str, List[str]]
def nonterminals(expansion):
return re.compile(r'(<[^<> ]*>)').findall(expansion)
class ExpansionError(Exception):
pass
def simple_grammar_fuzzer(grammar: Grammar,
start_symbol: str = "<start>",
max_nonterminals: int = 10,
max_expansion_trials: int = 100,
log: bool = False) -> str:
"""Produce a string from `grammar`.
`start_symbol`: use a start symbol other than `<start>` (default).
`max_nonterminals`: the maximum number of nonterminals
still left for expansion
`max_expansion_trials`: maximum # of attempts to produce a string
`log`: print expansion progress if True"""
term = start_symbol
expansion_trials = 0
while len(nonterminals(term)) > 0:
symbol_to_expand = random.choice(nonterminals(term))
expansions = grammar[symbol_to_expand]
expansion = random.choice(expansions)
# In later chapters, we allow expansions to be tuples,
# with the expansion being the first element
if isinstance(expansion, tuple):
expansion = expansion[0]
new_term = term.replace(symbol_to_expand, expansion, 1)
if len(nonterminals(new_term)) < max_nonterminals:
term = new_term
if log:
print("%-40s" % (symbol_to_expand + " -> " + expansion), term)
expansion_trials = 0
else:
expansion_trials += 1
if expansion_trials >= max_expansion_trials:
raise ExpansionError("Cannot expand " + repr(term))
return termReflection
The concept of fuzzing is intresting. Creation of small detail in code and inputs can be a great way to check your code and find bugs within it as well as checking a potentially random input into your functions or tool to see how they behave. Doing it with grammers may provide more code coverage within a tool but the one issue it might produce is the complex issue that might be produced when using and introducing grammars. With this being said it could be very beneficial to use as a team limiting the amount of manuel tests and inputs we as a team need to do.
Use Case
As some other students in our class have mention difficulty with xpath expressions fuzzing with grammar might help improve overall experience with xpath expressions. Grammar fuzing could have the possibility of generating xpath expressions to limit the amount of human created inputs.
Week 9
SE7
Summary
This section of the google engineering book focueses on being a good leader and some steps and suggestions on how to do so. There are three main points that they outline in this article Always be Deciding,Always be Leaving, and Always be Scaling. Always be Deciding is highlighting the importance of effective decision making. Taking in condiseration trade offs, long term and or short term effects, and being sure to obeserve others that your are leading. Always be Leaving is not being around the team you are leading all the time. The team should be just as productive when the leader is not there as it is when they are there. Finally Always be Scaling being able to navigate your team through succes and new projects. There may be an increase in work load but the number of people in the team is not changing so the leader needs to be able to organize the resources they have with the workload they have in an effective way.
Reflection
The three points being highlighted in this chapter are intresting and not something that I would have considered while managing a team. The point that stood out to me the most was always be leaving. At face value this point makes you second guess what you just read. It doesnt make a whole lot of sense till you read the idea behind it and it truly does make sense. Making sure your team is efficient without you as the leader is key to success.
Use Case
This is applicable to our class not only just for students but for teachers as well. When students are being a leader for an issue or the class session these points are important to consider even tho they might be on a much smaller scale than at google. Taking in consideration these point for how we are going to spend a class session is important.
FB7
Summary
In this chapter of the fuzzing book we are building on the previous chapter of Grammer Fuzzing by making it more efficient. Previously fuzzing grammar used a string-based algorithm and now using a tree-based algorithm. Using a tree-based algorithm allows keep track of our expansion status which allows us to see what elements expaned into another one through the tree. Each part of the tree has a node and these nodes have another node creating the tree like structure.
For example:
derivation_tree: DerivationTree = ("<start>",
[("<expr>",
[("<expr>", None),
(" + ", []),
("<term>", None)]
)])Use Case
The use of Grammar Fuzzing with a tree-based analysis could be very beneficial while working with chasten. We could impliment this in away where we get branchs of the function and what they lead to going all the way to the output. This could allow us to see where the program breaks and needs fixing. For example we could call to chasten analyze and then a node is creade for what analyze calls to and all the way though to the out put of that command and if anything breaks along the way we will know where.
Week 10
SE8
Summary
In this chapter of the google software engineering book we are taking a look at rules and regulations for a team when working on a code base. Engineering efforts typically have a set of rules on how to use and store various parts of a code base such as how the code will be formatted. In this sense rule are not just something to considre but should be seen as laws and it is important for all people who are contributing to the software abide by these laws. Something intresting to note is that each language has there own seperate set of rules at google but at the highest level they are somewhat similar. It is important to have these rules in place to great a common lanuage for all the coders to follow.
Reflection
This section of the book that is discussing the rules and regulations when working on a software project is not something I have considered. When working in a large team on a project its important that eveyone is on the same page but when there are no rules to govern how individuals write their code it might get messy. Having rules to set a standard on how to write code makes it more uniform and easier to maintain.
Use Case
Rules and regulations which we have discussed in class can be beneficial to us as a class. Having a set of standards to meet is important to making a coherent software project. We have aleardy set in place a process in how to get a pull request put through and merged to chasten which has helped out team.
FB8
Summary
In this chapter of fuzzing book we are looking at parsin inputs. We can use grammars parse and deconstruct a given input into derivativation trees of that input. This can be used in a simple csv parser:
def simple_parse_csv(mystring: str) -> DerivationTree:
children: List[DerivationTree] = []
tree = (START_SYMBOL, children)
for i, line in enumerate(mystring.split('\n')):
children.append(("record %d" % i, [(cell, [])
for cell in line.split(',')]))
return treeThis function will parse through and create a tree based on the csv file from the start to each individual characteristic of the csv file.
A more advanced verions of this parser that will handle quotes and more specifice detail within the csv:
def parse_csv(mystring):
children = []
tree = (START_SYMBOL, children)
for i, line in enumerate(mystring.split('\n')):
children.append(("record %d" % i, [(cell, [])
for cell in comma_split(line)]))
return treeUse Case
This could be useful if implimented into chasten. This could allow us to test servel inputs into the tool in some of the commands to see the resulting derivitave tree. This tree can allow use to see the beginning of the tree all the way through to the output. This function may be useful i in the future the chasten tool produces or takes in some kind of csv that we can make a visualization of for the user.
Week 12
SE9
Summary
In this chapter of the og the software engineering at google we are looking at code review. The simple defintion of this accoriding to the author us “code is reviewed by someone other than the author, often before the introduction of that code into a codebase”. Code review requires more than just looking over code at google they have a tool that they call “Critique”. At google they have 6 steps that they go through in order to review code:
- Writes a change to the codebase in their workspace and create a summary of it
- Author can use this for automated comments and or can do a self review
- Reviewers look at changed code review tool and post comments on the the changed that were made
- Based on reviews author changes codes and reuploads a snipet of the code to reviewers
- Reviewers check code to see if they are happy with the changes and use the “looks good to me” (LGTM) for confirmation
- Author is then allowed to upload the changes.
There are three parts to the review process. First is a comprehension and correctness check is done by another programmer. Second the code owner is looking for if this code is appropriate for the given code base.Thrid is a check that the code has readability. Checking the style that it is written and follows practices.
Reflection
This chapter provided great insight into how the people over at google check code for readiness and how it is integrated into the main program. The six steps that are listed by the google team for reviewing are great insights into how the review process works for code. The further explanation of how these reviews are done is good insight to use when potentially reviewing your own code.
Use Case
In our class we also have a set of steps that is used for review. In some cases with prs that I have had I would go through a similar list like google would such as asking for review getting input and changing it till its is ready to ship. I think this chapter can be useful for setting guidlines for our class in how to check and review code.
FB9
Summary
In this chapter of the fuzzing book is related to reducing failure inducing inputs. Fuzzing may create input that hard difficult and can produce errors when inputting them into the function and in this chapter they explain some techniques and ways of automation to reduce these types of failure inducing inputs. The first example that they use to express how failure occurs is using the “Mystery Runner”. Thi function has the potential to fail based on the randomly fuzzed input that it is given.
class MysteryRunner(Runner):
def run(self, inp: str) -> Tuple[str, Outcome]:
x = inp.find(chr(0o17 + 0o31))
y = inp.find(chr(0o27 + 0o22))
if x >= 0 and y >= 0 and x < y:
return (inp, Runner.FAIL)
else:
return (inp, Runner.PASS)This will run the function unitl it will fail proving that there is a possible failure inducing input. Below the code is a input that can break the Runner but we arent quite sure why yet.
mystery = MysteryRunner()
random_fuzzer = RandomFuzzer()
while True:
inp = random_fuzzer.fuzz()
result, outcome = mystery.run(inp)
if outcome == mystery.FAIL:
breakinput: ' 7:,>((/$$-/->.;.=;(.%!:50#7*8=$&&=$9!%6(4=&69\':\'<3+0-3.24#7=!&60)2/+";+<7+1<2!4$>92+$1<(3%&5\'\'>#'There are several ways to debug this input to find why its failing: Manual Input Reduction, Delta Debugging, Grammer Based Input Reduction.
Manual is essentially splitting up the input that is casuing issue and seeing which section of it is casueing this issue:
half_length = len(failing_input) // 2 # // is integer division
first_half = failing_input[:half_length]
mystery.run(first_half)
second_half = failing_input[half_length:]
mystery.run(second_half)A delta approach is similar to the manual approach but check half of the input and will chunking it farther down to find the spot where the input is breaking the program.
class DeltaDebuggingReducer(CachingReducer):
"""Reduce inputs using delta debugging."""
def reduce(self, inp: str) -> str:
"""Reduce input `inp` using delta debugging. Return reduced input."""
self.reset()
assert self.test(inp) != Runner.PASS
n = 2 # Initial granularity
while len(inp) >= 2:
start = 0.0
subset_length = len(inp) / n
some_complement_is_failing = False
while start < len(inp):
complement = inp[:int(start)] + \
inp[int(start + subset_length):]
if self.test(complement) == Runner.FAIL:
inp = complement
n = max(n - 1, 2)
some_complement_is_failing = True
break
start += subset_length
if not some_complement_is_failing:
if n == len(inp):
break
n = min(n * 2, len(inp))
return inpUse Case
I think this could be a viable way for us as a tema to check input that we are putting into chasten. The only dowside I think is how long it would take to implement this type of feature that may only used by us the developers. I could see something like this potentially being used to give the user feedback on their porblem inducing input into Chasten. This could help the user experience by pinpointing exactly where in their input they need to change and fix the input for the program to work.
Week 13
SE10
Summary
In this section of the software engineering is all about documentation and how to use it and write good documentation to help improve your code database. Documentation is important to explain to the reader how to run and use the tool that your are describing making it easy for the reader to follow. Having a quality documentation written with the tool helps you the developer and the reader to minimize confusion with how to and what the uses of the tool or program is. Unfortantly many oversee this key element to code development. Described in this chapter google takes documentation seriously. They act as if this is apart of the code in the software they are developing. There are several types of documentations that serve different needs. Choosing the correct one can enhance your documentation for the reader.
Use Case and Reflection
Overall I think documentation is a very important aspect to any software project. Out of the box documentation is needed to learn how a tool works and how to properly use it. For instance in chasten I spent a good chunk of time reading documentation and learning how the commands interact and the proper inputs. Throughout the semster there has been addition to the chasten documentation but I beleive there can be some improvements into how the tool works and a better piece by piece breakdown of how to run the tool with inputs.
DB1
Summary
This first chapter of the Debugging book is looking at debugging software. The first example in this chapter is talking about removing html code from several ines of code which looks like this:
def remove_html_markup(s):
tag = False
out = ""
for c in s:
if c == '<': # start of markup
tag = True
elif c == '>': # end of markup
tag = False
elif not tag:
out = out + c
return outThis simply checks wehter there are paranthesis on either side of the line to be removed. In this scenerio there is a bug that is ran into and we go through and try to find the but and how to solve it. Which brings us to a revised version of the previous code segment:
def remove_html_markup_without_quotes(s):
tag = False
quote = False
out = ""
for c in s:
if c == '<': # and not quote:
tag = True
elif c == '>': # and not quote:
tag = False
elif c == '"' or c == "'" and tag:
quote = not quote
elif not tag:
out = out + c
return outLater on tin the chapter they talk about some ideologies that comes with debugging such as the cause and effect chain which is giving a chain in which a bug can occur and how it may occur. Also a scientific method appraoch is mentioned and on how you can use this method to disnose a a bug and ultimatley debug it.
Use Case and Reflection
The cause-and-effect chain can be helpful to keep in mind when writing test cases for our code. Having a deeper understanding of the steps in the cause-and-effect chain can allow us to write better test cases to debug our program. Knowing that the chain starts with a human action that results in an error which then results in errors in the code may help us figure out how to debug a section of the program or an input that causes an error. Using the idea of the scientific method in this chapter can also be beneficial to look at bugs that are within the program or function. Taking the approach of the scientific method and creating a hypothesis as to what might be causing the error that the program or function is producing is a good first step in diagnosing the bug. Predicting what may happen when you modify a section or piece of code and checking it to see if the output is what you predicted it to be will help us debug a program or function. Overall this chapter gives key insights into the ideology to use when debugging a function or program.
Week 14
SE11
Summary
In this section of the software engineering at google book we are getting an overview in testing. Testing in software has been an important task even from the begining of coding and used to be a manuel step we had to take but now we can automate these tests. This allows software engineers to change and adapt code quickly. Althoough testing is used very often it is very hard to master. There are four bulltet points the author uses to desribe a simple test:
A single behavior you are testing, usually a method or API that you are calling
A specific input, some value that you pass to the API
An observable output or behavior
A controlled environment such as a single isolated process
While testing using a input and output expectaion type of test can check the how the function is designated to act and produce an output. Testing also provides safety for a program making sure no harm will be done or any unethical events occur from the code that was written.
Use Case and Reflection
The use of testing is important to include in your software engineering project. Making sure your tool and functions within this tool produce the expected outcome. If not this will render your tool not useable and users will not be inclined to figure your tool out. Tests in chasten are important since we are shipping it to the computer science department so we need to know that the tool is working as intended.
DB2
Summary
In this section of the debugging book we are talking about tracing executions which are monitoring how the a function is acting and producing. To get a visualization of each step of the debugging process we go back to the previous chapter to get the html remover and add some motifications to eat to see each step:
238 def remove_html_markup(s): # type: ignore
239 tag = False
240 quote = False
241 out = ""
242
243 for c in s:
244 assert tag or not quote
245
246 if c == '<' and not quote:
247 tag = True
248 elif c == '>' and not quote:
249 tag = False
250 elif (c == '"' or c == "'") and tag:
251 quote = not quote
252 elif not tag:
253 out = out + c
254
255 return outHow it is ran:
def remove_html_markup_traced(s):
sys.settrace(traceit)
ret = remove_html_markup(s)
sys.settrace(None)
return retremove_html_markup_traced('xyz')It will pridcue an output that looks like this:
call 238 remove_html_markup {'s': 'xyz'}
line 239 remove_html_markup {'s': 'xyz'}
line 240 remove_html_markup {'s': 'xyz', 'tag': False}
line 241 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False}
line 243 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': ''}
line 244 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': '', 'c': 'x'}
line 246 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': '', 'c': 'x'}
line 248 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': '', 'c': 'x'}
line 250 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': '', 'c': 'x'}
line 252 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': '', 'c': 'x'}
line 253 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': '', 'c': 'x'}
line 243 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'x', 'c': 'x'}
line 244 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'x', 'c': 'y'}
line 246 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'x', 'c': 'y'}
line 248 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'x', 'c': 'y'}
line 250 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'x', 'c': 'y'}
line 252 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'x', 'c': 'y'}
line 253 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'x', 'c': 'y'}
line 243 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xy', 'c': 'y'}
line 244 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xy', 'c': 'z'}
line 246 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xy', 'c': 'z'}
line 248 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xy', 'c': 'z'}
line 250 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xy', 'c': 'z'}
line 252 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xy', 'c': 'z'}
line 253 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xy', 'c': 'z'}
line 243 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xyz', 'c': 'z'}
line 255 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xyz', 'c': 'z'}
return 255 remove_html_markup {'s': 'xyz', 'tag': False, 'quote': False, 'out': 'xyz', 'c': 'z'}Use Case and Reflection
THe use of tracing excutions can be very beneficial when debugging code. When I have been debugging code in the past I have been using this without knowing but not on the scale that is being presented in this chapter. Rather I have just implemented brint statements to get a better understanding for what is going on in each part of a funciton to see where the potential error is occuring. Using tracing can be an important aspect to testing and debugging code in our tool for class. Taking these steps to trace back to where the error occurs may save us time and resources.
Week 15
SE12
Summary
In this section of the Software Engineering at Google book we are talking about Unit Testing. In thi chapter there is an emphisis on the importance of maintaining code and making sure that your tests are good and not flakey. Something to try to do with these test is to make sure they are unchanged. There are 4 main things that can influnce when and how a test might be changed pure factoring, new features, bug fixes, and behavior issues. Maintaing these are important when writing and continueing to work on a program. This chapter also suggest that there is a ratio that might be kept in mind when dealing with smaller unit tests and broader-scoped tests. One key insight from this chapter is that discussion of DAMP (Descriptive and Meaningful Phrases) and DRY (Don’t Repeat Yourself).
Reflection and Use Case
The will be important to the longevity of the two tools we are working on. Maintaing these code bases is important to do because students and teachers will be using this dail to imporove their computer science experience. One thing that I took incosideration was the discussion of DAMP (Descriptive and Meaningful Phrases) and DRY (Don’t Repeat Yourself). I believe in this case of our project a DAMP approch would be the most effective since we are going to be dealing students and professors that havent used the tool and might be looking for descriptive and meaningful code, test cases, and documentation.
DB3
In this section of the debugging book we are looking at asserting exceptions. The assertions help us check a large amount variabels or statements. Here is a simple assert statement to check if a varible is correct:
def test_square_root() -> None:
assert square_root(4) == 2
assert square_root(9) == 3The assertions will test the function and compare it to the expected out put and allows us we report back to the user wether it was correct or not usually in a true or false manner.
def remove_html_markup(s):
tag = False
quote = False
out = ""
for c in s:
if c == '<' and not quote:
tag = True
elif c == '>' and not quote:
tag = False
elif c == '"' or c == "'" and tag:
quote = not quote
elif not tag:
out = out + c
# postcondition
assert '<' not in out and '>' not in out
return outThis code segment uses a post condition that uses an asser for the condition of greater than less than in the previousfunction called. Checking to see if it is correct in the function.
Reflection and Use Case
Assertions can help us with a couple things when using our tools. With assertions we can create test cases but something to keep in mind these test cases will be simple and not dynamic, The assertions can check to see if the expeceted out put from our tools are being produced. Also we could use it in someway with the users input to check if there input matches the input that the tool is expcecting and correct to give and output for the tool.
Week 16
DB4
Summary
This chapter of the Debugging Book we are taking a look at statistical debugging. Statistical debugging is the idea that you can calculate the correlation between and excution and its failure. After running the program you can analyze the lines of code producing this failure and we can determine a percentage for each of these lines. This can help us narrow down where the issue is in the code based on these percentages. These percentages are calculated based on a percent of error. This might be taxing and difficult to implement it can ultimately provide great insight into the possible failure of your program.
Reflection and Use Case
After reading this section of the book I am very intrested in this form of debugging. I did not know this type of testing was possible until reading this chapter. Being able to break down line by line with a percentage of failure is great insight and very beneficial. I do not think this is viable for the chasten tool considering many of us are not proficient in writing base tests. I think that this would take too much time to implement and casue more issue and resource than its worth in this specific project.