Hi Allen.

> 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.)

Cheers,

Arran