Zoom meeting with Russell. We were going over some testing strategies and ideas on how to get better overall testing coverage. Pros and cons and costs of testing or costs of not testing. He was showing me a project that he is working on, and I was asking questions and taking notes. Here are a few things that I wrote down.

- The company that Russell works for allows for 4 hours a week for continuing education. That's pretty cool. I like that idea.

- We looked at some Lucid chart diagrams. UML diagrams, flow charts, and wireframe diagrams.

- Talked about stacking API socket requests using GraphQL vs simple or single Rest API calls.

- Patterns and strategies

- Using a data dictionary of sorts - For example: Defining a field, it's value, it's name, it's datatype, etc. We have a table inside of adilas called db_field_settings. It allows for things like: mins, maxes, validation rules, sort orders, names, aliases, special instructions, look-up values, defaults, etc. That's not exactly what a data dictionary is, but we will end up using more and more of this type of things as build out fracture. I have many needs for this level of control inside the application. Here is an example of a past entry dealing with elements of time and time templates (see EOT # 8004).

- Pseudo code, tracer code, or simple scratch files. Great way to get started and do mini prototyping without having to tie in everything.

- Different kinds of testing - unit testing, integration testing, and end to end testing. They tend to go in that order... if you are building new. They sometimes go in reverse order if you are adding tests for existing pieces. It depends on your architecture. Usually, you will have the most unit tests, then less integration tests, and even less end to end tests. That's the ideal.

- From Russell - If your tests are hard to write, then your code architecture may need some help.

- Providing a mock or mocked up data. Often, you may want to certify that your mock is similar to what really happens with real data. You want to make sure that you are comparing apples to apples. Ideally, you don't want to run tests on production servers. Most of the testing is pre-production, if possible.

- Russell and I were talking about time management. Often, we get pulled in different directions. We tend to go where we are needed. That may not always be where we want to go.

- There are huge demands in all areas. Backend, frontend, and even middle management stuff.

- With good testing and good testing coverage, it almost allows for a license to be almost careless in refactoring. If it needs fixing, you can just fix it vs leaving it alone because it may break something else. If something is wrong and you don't fix it, and you keep building on that piece or function, you tend to stack up technical debt.

- Everything has a connected ripple type affect. If you add more people, you will need to add more people to manage those people and what they are doing. Everything in a system affects other pieces of the puzzle or system (ecosystem).

- We talked about the challenges of a multi-use scenario or how our users use our product. Each company is so different. That can really make it kind of hard to test and predict every scenario. Welcome to our world.

- At some point, you almost feel like you have lost control of your users and what they do. It's almost too open or too freeform. There are pros and cons to that approach. It tends to come down to three things - 1. Permissions, 2. Settings, and 3. Templates or virtual instructions (rules and assignments).

- Lots of time talking about pressure from upper management, budgets, timelines, or others (even clients). What happens if you push things out too quickly? You end up getting what you pay for. It's really hard to get both fast code and good code (bug free and super stable). If you want the more stable code, you have to plan it out, build it out, plan the testing, check it off, and probably do more testing. The combo of both fast and good is really hard to get, especially if you have multiple developers involved. Long story made short, it takes time and planning.

- What price are you willing to pay? Great question.

- Learning about different tools and when to best use them. Each tool is best suited for a specific task and/or activity. Not every job only uses a hammer (and nothing else). It depends on the job. The hammer might be the correct choice, but it may not be. It all depends on job (project, task, activity, function).

- Start where you are and build from there.

- If your code is modular, well tested, that allows for future refactoring.