I’ve generally tried to apply a test-driven development methodology to writing answers to the challenges. But, the binary agents problem leaves me in the dark as I don’t have a single idea as to how I could write another test. Without writing a full solution, how might I write another test to better understand the binary agents problem?
In the bottom left corner of the page, it already tells you what each call to the function must return, so I am not sure how creating a test to assert if the value returned by a call to the function is true or false will be any different than just writing your code in the curriculum editor and running the tests. The tests have already been written to check your results so you don’t have to write your own tests.
I might be missing something about what you are asking. Maybe you give us an example of how you wrote a test for the another challenge and explain how it helped you better understand the challenge by writing the test? Then, I might have a better answer for you.
So, I could just write conditionals, or use an object to lookup values, and write a function which produces those outputs. But, if I have to write another test which I haven’t known what gets input to it until after I’ve already written the code, then I can’t use that method.
The tests have already been written to check your results so you don’t have to write your own tests.
I’ve found that I get a bit better of understanding by writing some tests of my own. Unlike other problems, I’m completely lost as to how to even write a test for this problem.
I think you should just write out your algorithm first in pseudo-code and then manually validate (on paper) the steps you write would produce the desired outcome for each test case provided. I like to write out my algorithms first and do a walk through to make sure I fully understand my algorithm before writing any code.
As far as writing tests go, I use those to validate functions still produce the same result on a “known” set of correct outputs which include all edge cases. That way, if I am refactoring my function, I can run the tests against it, to make sure I did not mess up the desired logic.