"The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing."
I've been working in a classical TDD style for the past 8 years, after at least that many years of Mockist TDD. A code base built in classical TDD style is much easier to maintain and change, but it does require more test setup which can easily be pulled into re-usable test data scenarios etc. We'll use fakes for services that are external(S3, DynamoDB, third party APIs, etc), we'll use real DB code pointing to h2 instead of say postgres other than that there's no test doubles. I would not go back to using mocks by choice.
Why would you want to? when the same unit test coverage will run under 1 minute, and be smaller easier to understand/change tests and can all be done on your laptop.
it all depends on your definition of unit/integration, what I am talking about as unit tests you may very well be talking about as integration tests...
one of the main points I was making is you shouldn't have significant duplication in test coverage and if you do, I'd much rather stick with the unit tests and delete the others.
Integration, E2E, and smoke tests are generally slow, flakey, hard to write. They should not cover/duplicate all the cases your unit tests cover.
They are good at letting you know all your units are wired up and functioning together. In all the codebases I've ever worked in, I would feel way more comfortable deleting them vs deleting the unit tests.
I've seen the following from pairing Junior and Senior engineers:
* Really talented junior engineers blossom extremely quickly. They will easily be a multiple better after a year vs not pairing.
* Middle of the road junior engineers can be stunted and continually depend on the decisions / skill of the more senior pair. Pairing them more frequently with same level or lower helps. Sometimes this doesn't happen because this lower quality pair goes significantly slower and the result may need some code review/cleanup cycles, but it's a worthwhile investment.
Paring with Ping Pong TDD works really well. Improves paring with frequent driver/navigator switches and improves TDD by having the navigator thinking ahead. Been doing it almost exclusively for 14 years.
Hiring for pairing is important. It's not for everyone, although not everyone has been in an environment where it's done well. I make sure to let people know they will be pairing full time on my teams and ask if they are comfortable with that. Also won't hire anyone that would be significantly slow to work with (can't touch type, slow thought process)
The problem often is that scrum (or any iterative process) fails when it's not paired with good XP engineering practices. There's constant learning and change on the product side, which drives constant learning and change on the implementation side, the code needs to be constantly refactored to best handle the changes.
TDD/yagni/refactoring allows you to keep your code base nimble. I can't imagine doing an iterative process by slamming features in one after another without refactoring the code as you go to handle what "you now know", or not having good test coverage to support the changes you need to make.
Refactoring also shouldn't be something the PO is aware of, it's not a story, or a 2 month break from feature development. It's part of the job as each story is implemented. Yes, sometimes you don't notice a good way of doing something until some time passes and that area of the code becomes a bigger refactor than usual, just have to deal with it as soon as possible.
Yup. Play is built on top of Netty and adds value so my point is why not build it as a re-usable library (or set of libs) vs a Framework, it's really not any more difficult.
I like Play, currently using for a personal project. But ultimately looking forward to the day where frameworks are replaced by mixing and matching libraries where you get just what you need and wire it up exactly how you want to without any limitations.
On the JVM and especially since version 2.1 Play is one of the most lightweight/modular frameworks. At it's core it's just a fast/async http server. So why can't that just be a library you pull in and fire up in a main method?
You can have an IDE or somthing like sbt recompile your changes on the fly so you can get rapid feedback. Ultimately more rapid feedback comes for automated tests vs refreshing your browser and verifying something manually (unless it's UI/lookandfeel changes which are not generally limited by having to compile)
+1 on keeping things simple and not using a "F"ramework for every concern from the very beginning.
>in Java you have to make those architecture choices day 1.
That's just not true. Very easy and advantageous to start out with say a simple container-less app with in-memory/flat file persistence and build up as you need. It's no different in Java and much more the norm in other JVM languages like Scala/Clojure.
Sometimes solving the hard problem means jumping into a teamroom in front of a whiteboard and doing some serious brainstorming / design. That is the one thing that is very hard to do effectively over say skype. Often with remote developers this type of problem is solved by a single person without the input of others. Resulting in a less then optimal solution that only one person is knowledgeable in.
As far as really getting into the "zone". What I do is put my headphones on, pipe some white-noise in and in a minute or two it's no different then working by myself in my home office.
for better content on the subject:
https://martinfowler.com/articles/mocksArentStubs.html
https://martinfowler.com/articles/mocksArentStubs.html#Class...
https://www.thoughtworks.com/insights/blog/mockists-are-dead...
"The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing."
I've been working in a classical TDD style for the past 8 years, after at least that many years of Mockist TDD. A code base built in classical TDD style is much easier to maintain and change, but it does require more test setup which can easily be pulled into re-usable test data scenarios etc. We'll use fakes for services that are external(S3, DynamoDB, third party APIs, etc), we'll use real DB code pointing to h2 instead of say postgres other than that there's no test doubles. I would not go back to using mocks by choice.