Week 9 Tutorial
Code Review
Assignment 1 / Mandelbrot Debrief
Well done everyone for such a great effort in the Mandelbrot assignment. Take a moment to think about what you have been doing.
What was the best part of the assignment? What was the worst part? Did you learn anything from the process of doing the assignment (i.e., disregard the actual content of the assignment – did you have any insights into the act of programming?)
Remember, if you haven’t finished your assignment yet, it’s not too late – the late penalty is 1% off the cap per hour, so a submission up until 2am on Wednesday morning can still get a passing grade. And getting the assignment working is so very worth it – as your classmates can no doubt attest to.
ADTs
Designing a Card implementation
We have the Card.h file, which specifies the interface that a user can use to interact with our ADT.
However, the interface only tells us how to interact with the ADT, not how it works. You have full control over how you implement the ADT – in particular, what goes in your card struct.
The following typedef is included in Card.h:
typedef struct _card *Card;
This means that a struct card has to be implemented somewhere, but not necessarily in the .h file, as we have done with concrete types.
The way we implement this in an ADT is that you design your own card struct, with the fields etc that you need to implement your ADT.
Your task is to think about how you would implement the Card ADT,
and design your struct _card accordingly.
Think about what information your implementation needs to store, and how you could store this in the struct.
You will finish implementing the Card ADT in the lab.
Testing ADTs
Black Box
From the lecture:
“I’ve written this program, now let’s get someone else to test it for me!”
your program is a magical black box, where information goes in, and information comes out.
One of the ways we test an ADT is through black box testing. The ADT’s implementation is like a “black box” – something using the ADT can’t see how it works on the inside, and can just pass the ADT object around without being able to see what’s going on.
This means that we can only test the ADT through its interface functions.
Your task is to discuss how you could test the Card ADT through black box testing.
Focus for the moment on newCard, and cardSuit.
You will need to create your own testCard.c
file to write your tests in.
You will continue writing tests for the Card ADT in the lab.
White Box (Unit Testing)
From the lecture:
“As well as testing my whole program, I’ll test each of the small parts of it.”
faster and easier to check our small units first and then check the whole program
Another way we can test an ADT is through unit tests. We can treat each of the functions in our ADT implementation (including static functions) as “units”, and test them each independently.
This will require our tests to be within the Card.c file, so that it can have access to the struct, and to the static function.
Your task is to discuss how you could test the Card ADT through white box testing.
Focus for the moment on newCard, and cardSuit.
What are the differences between your black box and white box tests?
You will need to create a function in Card.c to write your tests in.
You will continue writing tests for the Card ADT in the lab.
In the lab
MandelbrArt Exhibition
In the lab have every Mandelbrot pair display their awesome work to the rest of the class. Everyone should feel very proud of what they have done – it is pretty spectacular.
Have the class walk around and check out the MandelbrArt submissions from each group in the lab class and vote on the best image within your tutorial.
Later in the week, we will be running the overall MandelbrArt competition, where everybody in the course will vote to determine the best work of MandelbrArt for COMP1511 17s2.
If you haven’t yet submitted something, it’s not too late – submissions for MandelbrArt are open until Tuesday night.
ADTs
The lab activities this week involve implementing and using ADTs; see the lab page for more details.