What would the perfect test suite look like? Well it would definitely fully test every bit of functionality. It would run lightning fast. And the test suite would be quick to write. That sounds great right?

Unfortunately these 3 goals work against each other. Increasing test coverage will increase the time spent writing and executing tests. Reducing test execution time will result in lower coverage.

This talk look at the properties of unit, integration and system tests in terms of what they test, how fast they run and how quick they are to write. Will look at how to get the most out of testing at each of these levels, how best to architect code for testing and where best to make comprises. Although by the end of the talk we won’t have quite achieved the Test Suite Holy Trinity, we’ll be a step closer.


Comments are closed.

Jos Elstgeest at 18:07 on 26 Jan 2018

Nice clear talk about the relationship between good architecture and good testing

Really good talk. He seems to have a lot of experience on the subject, and was able to communicate it well.

Really liked the talk, explaining the essentials that I had to learn the hard way, it's a little bit abstract, so people that don't know a lot about testing might not fully understand everything, but for moderate experienced developers and more it's a really great talk!

Bruno at 11:01 on 27 Jan 2018

Very interesting talk. I specially enjoyed the QA, but the speaker could incorporate some of those questions and answers in the talk.

Robert Broen at 16:08 on 27 Jan 2018

Good talk.
Please let slide with lots of code samples linger a bit longer than slides with only two words.

Nic Wortel at 16:18 on 27 Jan 2018

Architecture and testing are two of my favourite topics of software engineering, and this talk discusses both of them. Dave does a great job defining the holy grail of test suites, and then explaining why this is impossible to accomplish and why different types of tests all have their place in a test suite. Talking about testing is always hard because people use different terminology, or have different definitions of the same terms (there is no "ubiquitous language", some people would say). Although Dave established a common terminology to avoid confusion during his talk, I feel like it would be helpful to point to an external resource (such as Nat Pryce's or Martin Folwer's) explaining the used definitions more in depth. I also feel that Hexagonal Architecture / Ports and Adapters would be worth mentioning (if he did and I missed it, please excuse me). Nevertheless, this is a great talk both for people new to testing and for people who already have some experience with (unit) testing. I would definitely recommend seeing this one!

It was so good that I took notes on what to improve when I go back to work.

Bart Reunes at 08:44 on 29 Jan 2018

Very nice talk that explained the topic very well. I would love to see more of this speaker, keep them talks coming - good job!

Nicely put information about testing! I liked how was it put - especially valuable for people who just are starting with testing.

Let me start of with the fact that I expected a different type of talk. I thought it would go into actual suites and not the types of testing that we have.

Having said that, this was a great talk! You presented it well and the slides were very clear.
Not sure about the naming but after seeing the talk I can understand why you used that naming specifically :-)

Timo Schinkel at 15:40 on 29 Jan 2018

Well spoken. Liked the starting out with a story, it sets a nice starting point for the talk. Found the following part of the talk a bit confusing with the walking from the left of the screen to the right and back, while showing "high" and "low". Maybe get this part visualized better.

Liked the remainder of the talk.

Joey at 19:39 on 29 Jan 2018

Cool talk and nice examples about testing. Testing, in my opinion, does not get enough attention and this definitely hit the spot :).

Great for more advanced developers used to the idea of testing. I found it really really helpful and it gave me nice insights. I suggest leaving it like this(more advanced talk) and refining it even more.