Tdd

Testing is an integral part of software development that ensures your code works as expected. However, running tests can sometimes be a slow and cumbersome process, especially when you’re looking to quickly iterate on your code. I use a “secret” method that allows me to quickly run tests using custom tasks and key bindings in Visual Studio Code (VS Code). This approach is much faster and lighter than other solutions I’ve tried. ...

The 5 “rules” I try to follow in order to write simple RSpec tests. Let’s GO. 1. Max 2 levels of describe/context nesting Everything above 2 is a code-smell and causes alarm bells in my head to ring. The more levels of nesting you have, the harder it is to understand what a given example is doing. If you add before/after hooks to the mix, it’ll become even worse. I often reduce nesting by simply using example descriptions like that: ...

In the “TDD is dead” discussion unit testing and mocking is being mentioned frequently. DHH explicitly expressed how much he dislikes mocks and it seems like many people still connect unit testing with mocking or even confuse the two. In case you missed it Martin Fowler wrote a great article about what should be considered as a unit test. If you’re also confused about mocks and stubs I encourage you to read Mocks Arent’ Stubs. ...

Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that, I really do. For me practicing TDD in a rails environment is much harder than when I work on my OSS libraries. There are many reasons why TDD in Rails is just a bit harder than it could be but that’s a big, separate subject. In this post I want to explain that TDD can be fun! ...

Code metrics and code metric tools can be both helpful and harmful. The difference between the two is learning to interpret the results and use the feedback to improve yourself and your code. I have a lot of experience with code metric tools. Over the last couple of years I’ve used them on a daily basis. Tools measuring simple things like test coverage, lines of code [LoC] per class/method, naming, and column length along with more advanced measurements for code complexity, churn, and mutation coverage. This experience has taught me a lot about code quality and object-oriented design. I believe that the lessons learned and the time spend refactoring my code have made me a better programmer. As is usually the case, nothing’s perfect and I have noticed that I encounter very specific pitfalls along the way. Here’s some of them and how I deal with them. I hope that my experience can help you when you face the same problems. ...

I don’t have exact numbers but I believe TDD isn’t really popular amongst rails developers. This shouldn’t be a surprise given that the two of the most complex elements in the rails stack, models and controllers, are very convoluted concepts and are simply hard to test. When you’re building a typical rails application most of the business logic lives in the active record models and controllers. Testing controllers in rails is a bit cumbersome but I still encourage people to write tests for them. What about active record models? How do you test them? Is it actually possible to test-drive active record models? ...

When working on DataMapper and its libraries we put a lot of effort into testing. Our libraries must have 100% code coverage and even that is not enough. What we want to achieve eventually is full mutation coverage. What is that? If you’ve ever heard or used Heckle then you’re probably familiar with the concept and you can skip the first part of this post and read about mutant. Code Coverage vs Mutation Coverage If your library has 100% code coverage and you think you did a great job then I have some bad news for you. You did a decent job but there’s a big risk you missed a lot while writing your tests and there are bugs that sooner or later users of your library will discover. Sometimes it’s not a big tragedy, you’ll get a bug report, you’ll fix the bug and everybody’s happy. On the other hand there’s a risk your code base is big enough that bugs that are found too late might be really difficult to fix. This can even require a bigger refactoring just to fix something. That’s one of the reasons why mutation testing can you help you in catching bugs early enough and making sure your code is going in a good direction. ...

It really surprises me that there are people arguing that writing controller tests doesn’t make sense. Probably the most common argument is that actions are covered in acceptence tests along with checking if views are properly rendered. Right? Right…well that’s just wrong! Are you trying to say that your slow acceptance tests are covering every possible controller action scenario? Are you trying to say that, for instance, every redirect that should take place is tested within an acceptance test? Are you also checking every invalid request in acceptance tests? Are you telling me that your acceptance test suite takes 27 hours and 13 minutes to finish because you fully test your controllers there?! Oh I’m sure that your acceptance test suite runs faster and you probably cover only ‘the happy scenarios’ there…which basically means you miss A LOT of test coverage. ...

“Skinny Controller, Fat Model” is a well known best practice in Ruby community. Everybody seems to agree with it and follows it. It’s pretty clear what a skinny controller is. The question is what is a fat model and what should we do if it gets too fat? Even better, what should we do to avoid too fat model? I think many people still confuse Domain Model with ActiveRecord. It’s something more and in this post I will try to explain my new approach to writing Ruby on Rails applications. ...

RSpec is one of my favorite tools. I have literally fallen in love with this fantastic BDD library, especially with its second version. While using RSpec I realized it teaches me how to write tests. Yes, exactly - learning RSpec DSL, its syntax and structure of spec examples you actually learn the best practices in writing tests. RSpec, despite many built-in matchers, comes with a DSL for defining your own, custom matchers. It’s so easy that you’re not gonna believe this. ...