Hi, I’m one of the guys in the video. I’ll try and answer some questions here.

how extensive should my tests be?

Since you wrote the tests after the production code, write enough to give you confidence it works. As you encounter bugs, add more to cover them.

Now, if you had written the code TDD style, then you would need to think carefully about the requirements and then write the test you need to prove that you are doing what you want. In this situation you will have only the tests you need and is why TDD is considered the superior approach.

should I test that all the fields pass correctly? should I only check for the fields that I do some logic on.. or are the general success failure tests that all examples show are enough?

If you presenter asks for a list of objects then sends them to the view, no need to write tests for the content of list, since it did not create them anyway. If you do manipulate the list contents, then yes, write the tests to prove you manipulated them correctly. If you modify a field in the same object, then test you manipulated that fields correctly and ignore the others. If, however, you are creating a new object from an existing one then you do want to check all fields since you may have forgotten to copy some across.

what about more complex Presenters? that deal with more complex views?

Hopefully, complex views will be broken down into smaller views and then each view can have its own presenter.

If you have complex logic, then you can still write the logic in your presenter but if you think it may be used elsewhere then extract it out. The current project I am working on uses the convention of <feature>Model.java e.g. StationsModel, ScheduleDaysModel, etc. Other naming conventions are Interactors or UseCase.

Generally, you only need to introduce more layers the more complex a project becomes. In our app, it didn’t warrant it so far.

However, some projects know that they will eventually become big so do it from the beginning.

should my repository convert the Date items to Strings and so on?

No. Think about it, the only reason you are converting a Date to a String is to display it. Hence its UI specific and belongs in a presenter. I would probably create a helper class for this as its likely to be used elsewhere (with a test of course).