Questions tagged 'authentication':

Being the new member of a team comes with lots to learn. There's a risk that Chip will interrupt the flow of the team while he catches up.

Chip was born into the programming world in the golden era of TDD and thus was presented with write-the-test-first design patterns in many tutorials and guides. A practice which chafed at him from early on but he spent way too long trying to get comfortable with.Chip's main production app, filterbuildscheduler, has nearly complete system, model and job tests. At time of writing: 1,073 passing tests.On the other end of the spectrum, Chip only has 462 tests in his other production app: liters_tracker. While the codebase is smaller, the test coverage is also smaller. The main part of the application is a forward-facing stats and story viewer. That part of the app has robust testing coverage. The back-end, data entry and reporting side that is only really touched by 3 people occasionally is lacking in some coverage.Instead of writing tests before implementing code, Chip has found it much more comfortable and natural to inject a final review-everything-and-write-tests step into his development-deployment cycle. He has found that performing a final inspection that includes writing tests, cleaning up, fine tuning, and refactoring always leads him to discovering some hidden mistakes, conflicting ideas, unused methods, slow code, etc.Chip believes the most important tests are system and feature that test the full flow of data from beginning to end to achieve the desired result. While harder to write, knowing the whole system works in concert to produce the desired result is the key.If your interest is piqued, read on for a more nuanced delve into Chip's thinking on this matter.======================================================================While TDD seems to Chip like a good moral practice, akin to 6-month dental checks, it often ran afoul of how he approaches software development.The practical use case for TDD is a piece of straight-forward, encapsulated code. When you know exactly what you are about to do, writing a test for it first is very achievable. I need a new method: Post#has_answers? 1. Write a test: A. When a Post is not a question, it should return false B. When a Post is a question, 1. And it has one or more associated answers, it should return true2. Write the method3. Ensure the test passesBut most of the time, Chip starts with a broader scope: "I want to retrieve, store, occasionally update and present my StackOverflow reputation and badges on this site."When starting on this feature, there are a few paths Chip could take and he usually likes to start down one of those paths and see what he finds:1. Retrieve reputation and badge info from SO profile A. Does SO have an open API? B. Does SO offer a JSON representation of a profile? C. If not A or B, we might have to get and parse the HTML of the SO profileStarting with a specific test at this point is impossible (after doing some research, C was the answer).We're still not to the level of specificity required of a good test. So Chip starts toying with ideas and trying some strategies. He eventually settles on using Net::HTTP and  Nokogiri in an ApplicationJob, but once he gets into the flow of tinkering and building, he rarely stops moving forward to go write failing tests first.Which leads us to Chip's preferences (from his upcoming memoir):1. Don't test what Rails (or Ruby or a gem) does for us.2. Test behaviors, not implementation3. Write more or more in-depth tests for dense and complicated code 4. Write tests that explain what a feature is supposed to accomplish, they serve as documentation

I worked with Chip at 20 Liters for 8 years. Before that, we worked at Red Cross together for 7 years. What do you want to know?You can reach me at amanda.meldrum@gmail.com or (231) 301-3189