The Page Object Model pattern was a thing long before Protractor and even Testacular were ever created. POM is a design pattern for Selenium WebDriver, and it is basically a way to structure your e2e test code so that it is more maintainable, readable, and reusable. In Protractor, we code in JavaScript, but what we are doing is very similar to the code of various WebDriver languages; selecting things from the DOM. This DOM selection code comes up quite a lot, and the POM allows you to define variables in another file so they would only need to be changed in at most one place. Let's take a look at an example of protractor tests without the POM:
0 Comments
I've been struggling to wrap my head around how to not only test directives, but how to approach teaching others how to test directives. I've been working on this github page with examples of common AngularJS things and how to test them, and how could I even pretend the list was complete without covering directives? I was looking at two resources today that opened my eyes a little bit, and I'll try to convey what I learned in this post.
Brandon Braithwaite is a developer from the UK with a solid TDD background and deep knowledge of unit testing so naturally his blog is a great place to learn about unit testing for your Angular projects. In particular, this is a great page with tons of links:
http://www.bradoncode.com/tutorials/angularjs-unit-testing/ It's 10pm, and I just got home about 15 minutes ago from the trek to NYC. I was at another software development meetup event today, but this time it was different; this time I was giving the presentation! During the last day of my Angular class I had to present my project: ng-nj.org. When I was finished I thought to myself, "Hey, I kind of want some more of that", and I was finally feeling knowledgable enough to be able to give other people some solid advice so I made an event happen and gave a presentation.
I was at the book store today, and a book caught my eye that was titled, "How Google Tests Software". To my delight, it was a book about unit testing. But it wasn't really a technical book about unit testing with any specific testing framework. It was more of a book about how Google is able to break down it's huge offering of services into small areas that over and over ship quality software fast. Page 6 of the book talks about the roles at Google; the different programming positions you could apply for if you wanted to work there. I thought this part was extremely interesting, and I couldn't help but visualize how I was doing all of these roles of my current job. It would be an interesting thought experiment to scale out the "TDD developer role" across a few people, and I really like the elegant way Google does it.
|
AuthorThe posts on this site are written and maintained by Jim Lynch. About Jim...
Categories
All
Archives
March 2023
|