This forum is provided to promote discussion amongst students enrolled in
CITS5501 Software Testing and Quality Assurance.
If posting a question, it's suggested you check first whether your question
is answered in the unit Frequently Asked Questions (FAQ) list, and use the search box
(on the right) to see if an answer to your question has already been posted.
Please consider offering answers and suggestions to help other students!
And if you fix a problem by following a suggestion here,
it would be great if other interested students could see a short
"Great, fixed it!" followup message.
Hi,
I had a question about the behaviour you would be expected to test for the constructor 'LightingCommand'. This is more of a general question as well for testing constructors. If you're testing a constructor, should you also test that the created object performs its intended function? In this context, on top of checking whether all the fields are stored correctly, should you also check whether the LightingCommand is able to correctly execute the Light Source? I think this would be logical since LightingCommand only has one primary function and especially since the constructor is so simple. Am I breaking any testing rules by doing this?
Have a good day
> I had a question about the behaviour you would be expected to test for the constructor 'LightingCommand'.
Unfortunately, I can't answer that. It's up to you to apply what we've covered in lectures and labs, make use of the prescribed reading, and demonstrate in the project that you know what you should be testing. If I say exactly what students are expected to test, then that defeats the purpose of the assessment, which is to show mastery of the relevant concepts.
Usually in university courses, you'll get much more useful answers to questions if you phrase them in terms of general principles or non-assessment examples.
> If you're testing a constructor, should you also test that the created object performs its intended function? [snipped] Am I breaking any testing rules by doing this?
Based on the general principles we've looked at, what's your opinion?
When asking a question about the unit content, it's always better to show some initiative and say what you think should be the case, but why you're unsure. Point to particular bits of the unit content or prescribed readings that are relevant, and explain what it is about them that's unclear. This not only helps you get an answer quicker, it helps improve the unit content, if something in the content is contradictory or unclear.
(This is good practice in the workplace, as well. If you're asking a colleague or supervisor a question, make it easy for them to answer - say "I think the options should be one of A, B and C, for reasons X, Y and Z. But I'm unsure which is really the case - can you assist?". It's then often very quick for them to say something like "The answer is A, because of reason X. Reasons Y and Z don't apply here". So you're saving other people's time (which is polite) and showing that you have initiative.)
When asking a question about the unit content, it's always better to show some initiative and say what you think should be the case, but why you're unsure. Point to particular bits of the unit content or prescribed readings that are relevant, and explain what it is about them that's unclear. This not only helps you get an answer quicker, it helps improve the unit content, if something in the content is contradictory or unclear.
Hi Arran,
I share some concerns raised by OP regarding the project specification. The instructions ask us to "apply input space partitioning to the constructor," but they don’t clarify what exactly we should test — specifically, what we should design test cases for. Consequently, I’ve assumed that our responsibility is limited to testing the behavior of the LightingCommand constructor itself. However, I’m unsure if this is the correct interpretation, which has led to some confusion.
My understanding is that we are not responsible for validating Location, LightSource, or State objects in the test cases. If these objects are not null when they are passed to the LightingCommand constructor, they should be considered valid; otherwise, their corresponding constructors should have thrown an error. Additionally, as we learned in class, Java APIs generally assume that parameters are non-null unless explicitly specified otherwise.
As a result, I am having trouble with identifying three distinct characteristics for LightSource. While there are three parameters, I cannot partition the values for LightSource because, based on my understanding, it only needs to be valid. I considered comparing the expected state with the current state of LightSource, but since there’s no available code to retrieve the current state, it appears impossible to write code for the corresponding test case.
I would greatly appreciate your clarification on whether I’m approaching this correctly. Many of us are facing tight schedules as the semester concludes, and I’ve noticed that Q7 has caused confusion among several students. Since Q8 depends heavily on the outcome of Q7, it would be helpful if you could point out where I might be misunderstanding the requirements or suggest a different approach I should consider.
I think your reasoning is valid - it's difficult to come up with many sensible partitions, based on the general principles we've looked at in class. A constructor with a more complex behaviour (e.g. exceptions being thrown) would therefore probably have been a better choice. But I don't want to make the assessment any harder at this stage, so I instead propose to make the question simpler - just one partition is needed, and 2 test cases. (If there's one partition, it follows there must be at least 2 test cases.)
I think with that amendment, question 8 becomes much easier, and question 7 should be relatively straightforward (but does require you to take care in explaining what your reasoning and assumptions are). Do you consider those changes would make the questions fairly straightforward? If so, I'll amend them in the spec.
I think your reasoning is valid - it's difficult to come up with many sensible partitions, based on the general principles we've looked at in class. A constructor with a more complex behaviour (e.g. exceptions being thrown) would therefore probably have been a better choice. But I don't want to make the assessment any harder at this stage, so I instead propose to make the question simpler - just one partition is needed, and 2 test cases. (If there's one partition, it follows there must be at least 2 test cases.)
Hi Arran,
I've approached this question differently. For ISP I'm applying it to the fields of the objects and not the objects themselves, e.g. Instead of partitioning Location, I'm partitioning the name of Location. Is this ok? Or is that an incorrect use of ISP?
Not OP or Arran but I don't think this kind of partitioning is relevant to testing the LightingCommand constructor specifically. Since the LightingCommand constructor takes Location and LightSource objects as parameters, it is a precondition of the constructor that the objects be validly constructed. I feel like partitioning the fields in this way is really testing the constructors for the Location and LightSource objects, rather than the LightingCommand constructor. So I think what OP and Arran have arrived at makes the most sense - one partition with 2 test cases.
> I've approached this question differently. For ISP I'm applying it to the fields of the objects and not the objects themselves, e.g. Instead of partitioning Location, I'm partitioning the name of Location.
In cases where a class consists of "plain old data" – i.e., the class doesn't do any significant abstraction or information hiding – then partitioning up a parameter of that class will amount to pretty much the same thing as partitioning up its fields. If the class does do information hiding or has invariants, then the domain might be smaller (and we might not have access to the fields at all).
Let's look at some concrete examples. If some method takes a primitive type as parameter (e.g. an int), then things seem straightforward – we partition up the range of possible ints. If the method specifically excludes some values as being undefined (maybe 0 is never allowed to be passed), then that makes our domain smaller.
If we have a class which basically is just a wrapper around, say, 3 ints, then we can partition objects of that class just by partitioning the individual ints.
But suppose we have a Date class, with year, month and day probably implemented as ints, but which are only exposed via "getter" methods (and which are presumably constrained by class invariants). A Date class presumably constrains the month to be in the range 1-12, and the day to be a valid day for the month. In that case, we don't have direct access to the field anyway, so it doesn't really make sense to talk about partitioning them, and even if we did, many of the possible int values are ruled out by the class specification. It would make more sense to partition the class based on properties like: is this the first or last month of the year? Is the year positive, 0 or negative? (We're unlikely to schedule meetings for 10 BCE, but I suppose historians might like to accurately model such dates.) Is the day the first or last day of the month? (And if we are testing a constructor which promises to throw exceptions when an invalid day is supplied, our partitions would include invalid days as well - but those would be partitions used for testing the constructor of class Date, not partitions for methods that use class Date or take it as a parameter.)
Not OP or Arran but I don't think this kind of partitioning is relevant to testing the LightingCommand constructor specifically. Since the LightingCommand constructor takes Location and LightSource objects as parameters, it is a precondition of the constructor that the objects be validly constructed. I feel like partitioning the fields in this way is really testing the constructors for the Location and LightSource objects, rather than the LightingCommand constructor. So I think what OP and Arran have arrived at makes the most sense - one partition with 2 test cases.
Hi Gihad,
Yes, if we're testing some method (or constructor) myMethod that takes in some reference type MyClass, then we can assume that any instances of MyClass are validly constructed – if they aren't, then either there's a bug in the constructor for MyClass (which would be caught in other tests), or a bug in the Java runtime (usually unlikely, but possible).
Not OP or Arran but I don't think this kind of partitioning is relevant to testing the LightingCommand constructor specifically. Since the LightingCommand constructor takes Location and LightSource objects as parameters, it is a precondition of the constructor that the objects be validly constructed. I feel like partitioning the fields in this way is really testing the constructors for the Location and LightSource objects, rather than the LightingCommand constructor. So I think what OP and Arran have arrived at makes the most sense - one partition with 2 test cases.
Ok that does make sense thank you.
Just another question, wouldn't two partitions make sense here (I'm not sure how much detail I am allowed to disclose)?
Gihad might be using the term "partition" loosely, in the sense of "a partitioning". So a partitioning of some domain X might give us two (or more) partitions.
Not OP or Arran but I don't think this kind of partitioning is relevant to testing the LightingCommand constructor specifically. Since the LightingCommand constructor takes Location and LightSource objects as parameters, it is a precondition of the constructor that the objects be validly constructed. I feel like partitioning the fields in this way is really testing the constructors for the Location and LightSource objects, rather than the LightingCommand constructor. So I think what OP and Arran have arrived at makes the most sense - one partition with 2 test cases.
Ok that does make sense thank you.
Just another question, wouldn't two partitions make sense here (I'm not sure how much detail I am allowed to disclose)?
