Jason Fleetwood-Boldt

Achieving Developer Excellence with Automated Testing

Top Tags

Latest Post

GDG Web Dev Fest @ Google NYC (18 Jan 2023) React Meetup @ Wix Playground (17 Jan 2023) Effective Story Writing for Software Teams Big Tech Won’t Save Us When Rails Ejected Node and the History of Compiled JS in Rails

JFBCodes on Youtube

Flaky Tests 4 - what to do about tests that fail at certain times of the day, week, month, or year. https://jfb.dev/
Flaky Test 4: Time Sensitive Conditions
If the test run order makes some tests flaky, then you don't have hermetic tests. https://jfb.dev/
Flaky Test (3 of 5)
The Agile Premise You may have heard of the iron triangle of project management: "Scope, cost, quality. You can't have all three, so choose only two." This means that: • If the scope is large and the cost is cheap, then it probably won't be very good • If the scope is large and the quality standard is high, then it will be expensive. • If you deliver it to a high-quality standard but cheaply, then can only have a very small scope. Scope, cost, quality — you can only pick two without negatively affecting the third. In agile software development, we have an answer to this question: and here’s the agile answer. We always the best quality— we never want to compromise on quality. That’s a lever we picked to stay in place. Cost (which is the same as time, assuming people get paid by the hour or by the day) is a lever we manipulate through the scrum process by doing sprints with a short fixed timeframe. That’s it — we don’t plan too far ahead, we don’t plan 3 or 6 or 12 months out— instead, we work a little blind to long-term considerations and focus only on the immediate future of the next sprint. And that leaves us with scope. Scope is the only lever left and the only thing we can do at sprint planning is to carefully decide what is a reasonable scope for 1 sprint’s worth of work. So in essence, when we’re doing agile scrum, we never really talk about quality or about time. Because quality is fixed because we always want the best quality, and time is easy— it’s just 1 sprint (either a week or two weeks or whatever your team uses). So we don’t need to discuss those things, we only discuss scope. If you’re in a business that’s writing software planning out too far in advanced or if your boss wants to dictate the time and dictate the scope, that is not an agile process (in fact, it’s waterfall) and you probably aren’t using scrum the way it was intended to be used. So again, just worry about the scope and work sprint-by-sprint to focus on highest priority needs. https://jfb.dev/
The Agile Premise
Race conditions in flaky tests. https://jfb.dev/
Flaky Tests (2 of 5): Race Conditions
Lets talk about flaky tests. #developerexcellence #automatedtesting #tdd #code #codecoverage #software #agiletok #techtoktips
Flaky Tests (1 of 5)
Please see the accompanying blog post: https://jasonfleetwoodboldt.com/courses/stepping-up-rails/ruby-arguments-equal-signs-colons-splats-double-splats-explained/ In this video I’m going to explain how method arguments work for the Ruby programming language. If you’re new to Ruby or you’re working on codebase you haven’t worked on before, it can get a little confusing seeing all of these symbols in Ruby method definitions and invocations. Many people who might be used to simpler programming languages see these colons and splats (a splat is another word for a star or asterisks) and are probably left wondering — what do all these things mean. Part of what is confusing is that Ruby started its life having only positional arguments. Then in Ruby 2, keyword arguments were introduced. On top of that, we have this special thing called rest arguments (that’s what you use the splat for) and then we have keyword rest arguments too. So this video will be a little long because I’m going to show you all of the rules. And it turns out that because of all the different options between positional and keyword and rest arguments, there are 14 different examples. So I’ll go through each example one by one to explain every part of arguments in Ruby. This video covers modern Ruby, and explains which versions of Ruby these concepts were introduced. - Positional Arguments - Positional Defaults - Rest positional Arguments - Keyword Arguments - Rest Keyword Arguments - Keyword arguments Defaults The Pyramid of Learning to Code: https://jasonfleetwoodboldt.com/courses/the-pyramid-of-learning-to-code/
Ruby Arguments: Equal Signs, Colons, Splats (*), Double Splats (**) Explained
https://www.tiktok.com/@jfbcodes/video/7235435143278628142
Fix the Hard Stuff
https://www.tiktok.com/@jfbcodes/video/7235432282742410539 Dev-Test Parity In the last video I talked about dev-prod parity and how important it is to have the same tooling and the same setup in development and production. This concept also applies to your test environment— in many cases, it’s important to run the code the same way in your test environment as in your dev environment, except when it’s not. When unit testing, you’re going to use mocks and fakes to replace some of the code that is ancillary, or adjacent to, the code you are testing (the code you are testing is called the system under test or SUT). You’ll only use fakes and mocks for code that is not part of the system under test. In many other cases, however, you do want dev-test parity. For example, you’ll want your test environment to use the same kind of database and backend infrastructure that your dev and prods environments do. When it comes to async code and concurrency your tests should deal with concurrency on par with development— that is, if the code runs async in dev then it should also run async in the test environment. The reason for this is that when it comes to controlling async code, you want to reduce the number of discrepancies between your test environment and your dev environment. Although there are exceptions, the bottom line is you should start from the baseline of keeping your dev environment and your test environment running things the same way. This is called Dev-Test parity spelling PARITY
Dev test parity
https://www.tiktok.com/@jfbcodes/video/7235428285998566702 Dev-prod parity means we run the same code the same way both in development and production. Now, there will be some exceptions for things like external payment processors so we don’t process real credit card transactions while development, but for the most part, you want to strive for having every part of the stack work in development the same way it works in production. So if you use MYSQL in production, you’ll use MYSQL in development. If you use Redis in production, you’ll also use Redis in development. The same is true for thinking about asynchronous vs synchronous code, concurrency, tooling, etc— if it works one way in production, we want it to work the same way in development. The absolute worst position to be in is having a bug on production that you can’t reproduce locally. That happens when there are small differences in how you set up your production and development environments, so this is actually a very critical thing to pay attention to when setting up your stack and pick tooling. It’s called dev-prod parity
Dev Prod Parity
Load More... Subscribe

Latest Posts

TikTok

https://www.tiktok.com/@jfbcodes

You missed

Uncategorized

GDG Web Dev Fest @ Google NYC (18 Jan 2023)

January 24, 2023 Jason
Uncategorized

React Meetup @ Wix Playground (17 Jan 2023)

January 18, 2023 Jason
Tech Industry

Effective Story Writing for Software Teams

October 3, 2022 Jason
Tech Industry

Big Tech Won’t Save Us

February 25, 2022 Jason