Can you have simple unit tests for complicated function? For example: Turing test for AI.
Do you always can find simple unit tests for any complicated enough function / algorithm?
1
$\begingroup$
$\endgroup$
closed as off-topic by Evil, xskxzr, jmite, Juho, Discrete lizard♦ Sep 21 at 12:02
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "This question does not appear to be about computer science, within the scope defined in the help center." – Evil, xskxzr, jmite, Discrete lizard
-
$\begingroup$ This question doesn't seem fully specified. What properties do you want the tests to have? I suggest editing your question to define your question more precisely; and tell us what attempts you've made to try to answer it on your own. $\endgroup$ – D.W.♦ Sep 18 at 9:41
0
$\begingroup$
$\endgroup$
The Turing test would make a very poor unit test because (a) it is difficult (impossible ?) to automate and (b) the evaluation of the test output to produce a pass or fail result is subjective. In fact, it might not even be possible to devise useful unit tests (in the usual sense) for strong AI - how would unit tests distinguish between true AI and a program that simply responded by rote ?
But simple unit tests for other complicated functions are certainly possible. As long as the function produces output that can be objectively evaluated then you can write unit test cases for it. For example, a Travelling Salesman Problem solver could be a very complicated program, but a unit test plan is very simple:
(a) test edge cases - 0 cities, 1 city, 2 cities
(b) test some simple cases with known solutions e.g. 3 cities in scalene triangle, 4 cities at corners of a rectangle, solved examples from TSPLIB
-
$\begingroup$ Even for difficult TSP cases (or any NP-complete problem, for that matter), testing a solution is usually going to be much less complicated than finding a solution. (I say "usually", because testing "no solution" certificates can be nontrivial.) $\endgroup$ – Pseudonym Sep 18 at 13:15
0
$\begingroup$
$\endgroup$
In the case of the travelling salesman problem, you can easily write unit test that find _ some_ bugs but not all: construct an instance and find a solution. Then increase some distance between cities that are part of the optimal solution and solve again. The shortest distance should not become less. And then you repeat.
An algorithm that doesn’t find an optimal solution ( when it is supposed to) would likely find solutions that are sometimes less and sometimes more close to optimal. So if you give it instances where the optimal value should have non- decreasing values a non- optimal solution might produce decreasing values sometimes.
