LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
Test Driven Development is a phenonemon every developer should be aware of by now. I can't believe I've been developing professionally without it, and have been using it in every project since I discovered it 5 years ago. But, applying TDD on UI logic can be challenging, even if you apply patterns like MVC, MVP or Presentation Model. Creating readable and maintainable unit tests that drive a Presentation, ViewModel or Controller is a big maintenance burden.
That's why our ASP.NET WebForms/MVC project jumped on the SpecFlow and WaTiN bandwagon. Using this beautiful combination we can now smoke test the overall behavior of the system, in addition to the large coverage of automated unit tests. Granted, this isn't the same as Acceptance Test Driven Development, but those smoke tests have been really worth their money. The functional abstraction that SpecFlow offers has proven to be a valuable aspect that allows us to keep our UI tests maintainable. In fact, the Gherkin matra Given-When-Then has even found its way to our test professionals.
During this talk, I'd like to share some of the basic principles behind SpecFlow and the most important aspects of WaTiN. Just like with TDD, there's a whole lot you can do wrong. That's why I want to focus on some of the best practices that worked for us. Anyway, if you're serious about building high quality products and system, check out what I have to share.