user11335: So this is a bit of outlier question.
I am writing a chess library, essentially from scratch. You can find much of the code here, with the intention of using it for a GUI and/or an engine. (The game is Grand Chess but for the purposes of this question it doesn't really matter.)
I am currently writing unit tests to verify that my functions work as expected. And I was wondering if there was some sort of library or database of suggested positions to test I can use and work from, categorized by whether they're Checkmate, Stalemate, Check, Legal, Illegal, etc.
tl;dr I am looking for a list of positions to unit test my code against.
You can find my current tests here, I add to them every few days. However, I want to make sure the tests are exhaustive before I go debugging the code. (Half of them fail currently).
Edit : to clarify : I am not looking for engine ("best move") tests. I am looking for board representation ("is this position checkmate") tests. I already have a few puzzles lined up for engine testing.

user12728: When reading your question, my gut reaction is that your scope is too complicated for unit testing.  I recommend a quick read through the free e-book Unit Testing Succinctly.  However, I have no experience writing chess code (maybe your paradigms are different) - although I do software for a living.
A unit test should be very simple and test a function that does 1 single thing.  Then you can combine the functions with some reasonable expectation that they will work.  For example, I would expect a unit test for each piece to determine if a particular move is legal.  A unit test for each piece to determine if it is putting the king in check.  A test for each piece to determine where it is attacking, etc.
Testing a position seems like a very complicated unit test and would be much harder to do thoroughly.  Instead write smaller tests against smaller functions and then know that those individually work - evaluating a position is just a matter of iterating over the simple functions.
If you want to test a position for a good (not forced) move, I think unit test's will artificially limit the long term development and strength of your chess engine... a binary result of a unit test will force your engine to make the same move every time.
I'd also look at adding unit tests for 'most direct' path to a mate with known endgames.  I'd look to add unit tests for traversing through known openings as well.  Mid game unit tests will be much harder - maybe plugging in a position and evaluating that the engine produces a usable result (which is a binary response).
For the question of evaluating a set of positions for your engine, you may do far better putting this question on https://stackoverflow.com/ with the "chess" tag.

11335: <p>So this is a bit of outlier question.</p>

<p>I am writing a chess library, essentially from scratch. <a href="https://codereview.stackexchange.com/questions/141425/grand-chess-domain-model-and-helper-functions">You can find much of the code here</a>, with the intention of using it for a GUI and/or an engine. (The game is Grand Chess but for the purposes of this question it doesn't really matter.)</p>

<p>I am currently writing unit tests to verify that my functions work as expected. And I was wondering if there was some sort of library or database of suggested positions to test I can use and work from, categorized by whether they're Checkmate, Stalemate, Check, Legal, Illegal, etc.</p>

<p>tl;dr I am looking for a list of positions to unit test my code against.</p>

<p><a href="https://github.com/asibahi/Stamma/blob/master/StammaTests/PositionTests.fs" rel="nofollow noreferrer">You can find my current tests here, I add to them every few days.</a> However, I want to make sure the tests are exhaustive before I go debugging the code. (Half of them fail currently).</p>

<p>Edit : to clarify : I am not looking for <em>engine</em> ("best move") tests. I am looking for <em>board representation</em> ("is this position checkmate") tests. I already have a few puzzles lined up for engine testing.</p>
 12728: <p>When reading your question, my gut reaction is that your scope is too complicated for unit testing.  I recommend a quick read through the free e-book Unit Testing Succinctly.  However, I have no experience writing chess code (maybe your paradigms are different) - although I do software for a living.</p>

<p>A unit test should be very simple and test a function that does 1 single thing.  Then you can combine the functions with some reasonable expectation that they will work.  For example, I would expect a unit test for each piece to determine if a particular move is legal.  A unit test for each piece to determine if it is putting the king in check.  A test for each piece to determine where it is attacking, etc.</p>

<p>Testing a position seems like a very complicated unit test and would be much harder to do thoroughly.  Instead write smaller tests against smaller functions and then know that those individually work - evaluating a position is just a matter of iterating over the simple functions.</p>

<p>If you want to test a position for a good (not forced) move, I think unit test's will artificially limit the long term development and strength of your chess engine... a binary result of a unit test will force your engine to make the same move every time.</p>

<p>I'd also look at adding unit tests for 'most direct' path to a mate with known endgames.  I'd look to add unit tests for traversing through known openings as well.  Mid game unit tests will be much harder - maybe plugging in a position and evaluating that the engine produces a usable result (which is a binary response).</p>

<p>For the question of evaluating a set of positions for your engine, you may do far better putting this question on <a href="https://stackoverflow.com/">https://stackoverflow.com/</a> with the "chess" tag.</p>
