caperren/school_archives
1
0
Fork 0
mirror of https://github.com/caperren/school_archives.git synced 2025-11-09 21:51:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

Added work from my other class repositories before deletion

Browse Source
This commit is contained in:
Corwin Perren
2017-11-29 10:28:24 -08:00
parent cb0b5f4d25
commit 5ea24c81b5
198 changed files with 739603 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
OSU Coursework/CS 361 - Software Engineering I/Assignment 1/final_submission/kwic.txt Normal file
View File

@@ -0,0 +1,31 @@
1. How did you decide what to test first? Would your final code change significantly if you changed the order of tests?
The process for deciding what to test mostly had to do with a logical breakdown of the core parts of the code so that
things that relied on others to work were done after those pre-requisites. So, for example, before we could do anything
first the document had to be broken down into sentences, then words. In that part, you could also change whether or not
the sentence breaks were handled with newlines or periods. Afterwards, you could then deal with rearranging the words as
necessary, handling determining pairs, and then excluding any words that were given as arguments. I don't feel like the
code would have been massively different if it'd been done in reverse, but it definitely would have been more difficult
to write. On top of that, you'd still have to think all the way through how the code would need to function, regardless
of the order in which you wrote it, in order to know what needed to be written in the first place. Also, if you
literally reversed the order of the tests, it could lead to you skipping the whole point of using tests (if you did it
incorrectly). Again, for an example, if you wrote a test that produced the final output of the program as the initial
input and expected a correct output, you'd either have to hard code many many values in to the resulting code while you
implemented them for real, or you'd end up writing all necessary code at once, which would defeat the purpose.
2. What did you think of test driven development, for this problem? What are the strengths and weaknesses of the
approach? Does it encourage/discourage certain kinds of program designs?
I'm torn about it. I feel that for this particular problem, it may have been overkill and actually hampered design
progress at times. The main issue was that for each major step, the output of the code often changed enough that many
of the tests had to be modified or rewritten to match. The definite strengths of this approach are that you can easily
tell when you change something that breaks the functionality of your code, and it will immediately produce an exception.
On the flip side, it does take much longer to write functional code depend on what exactly you're writing. I would
argue that the larger the application being written, the more important it would be to do this kind of testing.
Without it, you might be digging through hundreds of thousands to millions of lines of code to figure out what is
breaking. I can definitely appreciate the fact that taking the time to write the tests helps guarantee that it's doing
what you want, but I feel like it would be more useful in other programming contexts, like the one just mentioned.
I'd say this style of coding encourages program designs that have a consistent output even if the underlying code
changes often. For example, I feel like it'd be ideal for developing an API where once a standard has been created,
that API should function identically for a long time, even if the backend is changing constantly. In general, this way
of programming also encourages full coverage of edge cases, as you'll easily and quickly be able to test for them.