give us a hint

If you extend this Kata to allow for let's say 0 <= flats/sharps <= 25 and 100's of random tests, it would become more mature.

1. You are lacking random tests.
2. You are lacking edge case tests ((A) more than 6 accidentals, (B) more than 12 accidentals)
3. From the description it is clear that enharmonic equivalence is not applicable (Db != C#), however nothing is being said about octave equivalence.

• Does C############# get normalized to C#? (B)
• Does C########### get normalized to Cb? (A)
  --
  Other than that I hope this series continues at some point.

Well, I haven't looked at the whole composition, but at 7:20 (where there is a double barline, a key signature change using two naturals & five sharps, with the notation sempre p) the music is in B major for those 6 measures.

Here: https://youtu.be/iRkMBjuqpWo?t=439, it's linked to the minute 7:19, since the compass starts arround the beggining of the second 20. Also see the bars, starting from the third one, up to the next 6, it modulates from Bb Maj to A# Maj.

Also, this piece uses quite a lot of "unusual" scales, but this is not strange to Chopin compositions.

Chopin! no kidding... can you specify the six bars where this takes place?

The A# Major scale is more of a theoretical scale, usually the songs that could be in A# are written in its enharmonic equivalente Bb. This is done beacuse it´s more practical to only have 3 flats rather than have 4 sharps and 3 double-sharps.Yet some pieces, essentially in classical music, sometimes modulate to this scale during the song like Chopin's Polonaise-fantaisie in A-flat major, Op. 61, which modulates to A# major for six bars.

Can you please direct me to a piece of music written in the key of A# major? I'm looking for mor info. Thanks!

Ok, ok, I think it's done.

just a note...

Mmmmh, correct. I always thought that the @Test methods were instance methods of the same instance, and not creating different instances for each method... How weird... :o

But the loop still stays more "DRY" and easier to maintain. ;)

I'll fix it, just a note, by calling 40 different @test i call 40 different times the r, which then returns a different value so there are actually 40 different test, belive me i've checked.

Also, having the solution I use in the test class wouldnt be giving away a solution?
(Update) Nvm, I think I know what you mean now.

closer, but still some problems. ;)

• don't put your solution in the preloaded part, put it (as private method) in the test class
• make the solution setup runnable (return null;)
• random tests: .... xo wow... That's "a bit" random... Except that you'r doing all the tests with the very same value, so it's the same as having one single random test. x)

Note: instead of designing different test methods for the fixed tests, you could:

• either use one single method and use arrays and a loop to chain all the tests
• or design automated tests (@Parametrized stuff and so on). But that's quite complex to set up correctly in java, so I'd avoid that for the moment, if I were you. ;)

About the random tests: one single method with a loop inside:

    private SecureRandom rand = new SecureRandom();     // warning with the modifiers
    
    @Test public void randomTests() {
        for (int i=0 ; i<100 ; i++) {
            int r = rand.nextInt(150);
            assertEquals(expectedAttributes(r), Attributes.charAttribute(r));
        }
    }
    
    private Map<String,String> expectedAttributes(int r) {
        ...
    }

Ok, I think i´ve fixed everything