I'm with Anders Wallgrin. Anders is the CEO of Electric Cloud, which builds solutions for continuous delivery. Thanks for joining us Anders. >> My pleasure. >> Let's talk about unit testing a little bit. I mean, you've worked with a lot of things. What are some of the things you see working, not working teams approach? Review our initiation of unit testing. >> A lot of it depends on what are you starting with. If you are starting with a large existing code base that doesn't have good test coverage. You're probably goingto go off and do a certain set of things that's different than if you're starting with a blank sheet of paper. And can sort of mandate that we're going to do unit testing from the very beginning. But I think the former is a situation that a lot of us find ourselves in, and really it's important to kind of cover how you transform. How do you transform that situation into something where you've got a quality tested code base and can reap the benefits of that... You know, faster refactoring and more reliable code and bills and those kinds of things. And really, what a lot of people will say is, don't dive in and try to get 80% coverage on existing code. Because you're going to spend the next six months doing nothing but that and that really doesn't help anyone. And so, what a lot of people will say is, there's a lot of techniques you can use. Like If you touch a piece of code, write some tests for it or do what some people call boundary testing. If there's a kind of a natural API boundary or a service layer boundary, then do some testing around that. So, that you can certainly do contract validation if you will and so, there's a lot of tricks that you can play. And things like for example, mandating that your people do test driven development, especially for bug fixing. So that if you're fixing a bug, write the test that confirms the bug before you actually fix the bug. It's actually, it's pretty interesting how quickly you start to develop a feel for how to write good tests. And if you can use that as kind of the camel's nose under the tent to get people to doing test-driven development. And then of course, if you can get even more sophisticated than structuring things like behavior driven development. Where you can use these testing frameworks that allow non programmers, still technical people. But architects and program managers and project managers and those kinds of people to write behavior driven tests. That you can then use almost as a specification for the user stories that you need to do to finish features. So once you get there and once you have good unit test coverage, you can then move a lot quickly. You can rewrite subsystems and refractor at will. Because you have these tests and can rely on them to keep you honest and keep things working. Those are some great perspectives on unit testing. >> Thanks Andrew. >> You're welcome.