Right from the beginning at my second post...
Previously I did not concern myself with the special functions too much as I didn't find they did anything too important, just writing them as per convention so they would function as I deemed fit (Sure I could compare objects but I never thought I would use it for, say, testing if an object is in a correct state). However I wrote that they were something neat to learn but after going through the course and the assignments I realize how useful they can really be. I think the most often used one would be the __str__ method which could be used to not only compact our code, but would be extremely useful in producing a relevant output for the user. It could also be used as a tool to assist in debugging as I would be able to see the state of the object and not the mess of the object's id which I would be interested in.
Right after that we started on recursion I wrote that I thought it to be an extremely useful concept to know and obviously that is the case. Looking back at just Assignment 2 we had to create the minimax method while just given the algorithm of how it should be done. If I hadn't taken the time to completely understand recursion I guarantee you that I would have easily spent double the amount of time I spent writing minimax. Each time the function ran I had to know and have a clear image in my mind what it was doing in certain cases and why. As I wrote before, starting with the simplest cases and slowly moving forward and drawing/brainstorming on a piece of paper was indeed the best way to get started and to wrap my mind around the problem.
I learned to experiment with the code in order to see what worked and what didn't. While minimax was a single algorithm, there were many more, some efficient some not so much, ways to write it. I mean even in Assignment 2 we were given starter code which had the Subtract Square game implemented which was part of what we did in Assignment 1. It was a quite different implementation of what our group had done but worked similarly, we wrote it in a certain manner so it would function in a specific way, to interact with the other classes in the way we saw best. Now I'm not saying there is a single best way/solution for every problem, but each has its own benefits as well as drawbacks. All in all it also really does depend on the way you approach the problem too; many different paths to a single destination I suppose.
Monday 6 April 2015
Wednesday 1 April 2015
Week 10
So week 10 we focused on, basically, assuring that the code we write is performing exactly what we expect and not passing simple tests by sheer luck, that there is no flaw. So in order to do this, we first must identify good test cases until we are confident in our code, testing the boundaries, any special cases, different sizes if applicable, etc. in other words:
In this specific case, we expect the result to be x. Now run the code and see if you get x.
Of course that's just simplifying everything. To test it we can use 'assert' statements which basically allow you to test if x condition is true, the code is correct, else raise an error in a simple line. Not really difficult to understand but just know the syntax is kind of different:
assert (condition), (error message)
In order to even be able to test anything you have to create all the applicable objects and appropriate circumstances to test a specific case. We can use fixtures which involve being able to easily create/remove the objects required in order to test each case.
Now I had previously interpreted that incorrectly in the sense that we can simply create the objects ourselves at the beginning of the class and make adjustments accordingly inside the test cases. But obviously that would be tedious with a lot of test cases so we instead use help to create separate instances easily each time to prevent the tedium.
Once our code gets even more complicated, all you can do is really take it step by step and look over each individual line independently and as a whole. Know what it does and how it interacts with everything else. Unintended interactions, bugs will almost always be created and it's never easy to find and fix the minute subtleties in your code!
In this specific case, we expect the result to be x. Now run the code and see if you get x.
Of course that's just simplifying everything. To test it we can use 'assert' statements which basically allow you to test if x condition is true, the code is correct, else raise an error in a simple line. Not really difficult to understand but just know the syntax is kind of different:
assert (condition), (error message)
In order to even be able to test anything you have to create all the applicable objects and appropriate circumstances to test a specific case. We can use fixtures which involve being able to easily create/remove the objects required in order to test each case.
Now I had previously interpreted that incorrectly in the sense that we can simply create the objects ourselves at the beginning of the class and make adjustments accordingly inside the test cases. But obviously that would be tedious with a lot of test cases so we instead use help to create separate instances easily each time to prevent the tedium.
Once our code gets even more complicated, all you can do is really take it step by step and look over each individual line independently and as a whole. Know what it does and how it interacts with everything else. Unintended interactions, bugs will almost always be created and it's never easy to find and fix the minute subtleties in your code!
Subscribe to:
Posts (Atom)