In actual tests, exceptionHandling() there are tests that try to augment two matrices of different Field types. This is definitely not expected.

The numerator and denominator of Q are long which means it'll break after either of them have exceeded long range.

This is happening in the square test, where the input is a matrix with values like 1303471066566290185/3597965028172970961.

(It should be BigInteger, not long)

Testing for methods that return T (e.g determinant) does not perform type check on the method signature, while some methods that return Matrix<T> does, and some doesn't (e.g add and subtract). Type checking should be consistently mandated by the tests for all methods.

C is not a proper field because the components are doubles, and doubles are not fields. They will be affected by floating point errors in arithmetic operations.

Matrix and Field have very different structures: all Field methods return values of type Field but not the implementing class, while Matrix requires returning Matrix<T> but not Matrix<Field>. It is unreasonable to require Matrix doing what Field doesn't do, and besides, this makes working with fields unreasonably clunky.

The standard workaround for this is to use public interface Field<T extends Field<T>>: see https://stackoverflow.com/a/8407944

(This will also make ZERO and ONE capable of becoming static, which is a good thing.)

The description is too long to read effectively, but 70% of the description are about the implementation of Field class which are not relevant to the task in the kata itself. It should be wrapped in collapsible sections to reduce the effective size.

See: https://gist.github.com/pierrejoubert73/902cc94d79424356a8d20be2b382e1ab

It is unclear whether methods that return a Matrix<T> should return a new instance, or modify the original instance and return itself. (The latter is the standard in most early Java types like Date, Point, Rectangle... It is considered a mistake, but, well, it is what it is.) This should be clarified (and perhaps tested).

Similarly, does the operations on Field modify and return itself, or do they return a new instance instead?

For a kata of this size with this many methods to implement, the required constructor/methods should be added into initial code as stubs (probably with throw UnsupportedOperationException("TODO: {method name}") inside the methods so it fails exactly inside the method when invoked). Otherwise it is very difficult to get code that could compile to the sample tests, and no testing are possible until the method are implemented/stubbed.

What happens if a 2d array that contains arrays of different lengths are passed in? Will this happen in the tests? If this happens, how should we handle it?

Constructor and get(int i, int j) bullet points are missing a proper line break between the method signature and its description.

The ONE and ZERO methods should probably be static.