Automated tests/ jest/ TDD/ CI/CD/ syuper-test/ By Nima Shokouhfar

1. Styles

1.1. others

1.1.1. styles

1.1.1.1. bad

1.1.1.1.1. Very bad

1.1.1.2. good

1.1.1.2.1. very good

1.1.1.3. not as good

1.1.1.4. not as bad

1.1.1.5. important

1.1.1.5.1. Very important

1.1.1.6. warning

1.1.1.7. link

1.1.2. AUTHOR

1.1.2.1. Nima Shokouhfar

1.1.2.1.1. Linkedin

1.1.2.1.2. Youtube

1.1.2.1.3. Medium

1.1.2.1.4. Github

1.1.2.1.5. upwork

1.1.2.1.6. main website: ideariver.ca

1.1.3. Styling Version

1.1.3.1. 3.0.1

1.2. main

2. main

2.1. CI/CD pipeline

2.1.1. avoid pushing disfunctional code to the server

2.2. why

2.2.1. why write test?

2.2.1.1. CHATPGT Era & code generators era

2.2.1.1.1. We all use chatgpt to write code these days. However, these tools are not perfect and make stupid mistakes that human can never catch

2.2.1.1.2. So, if you use these tools and not writing test, the system can get unstable very fast

2.2.1.1.3. This is why I believe writing test in our time is the matter of utmost importance

2.2.1.2. refactoring

2.2.1.2.1. When changing the code, you do not create a time bomb

2.2.1.3. Maintenance

2.2.1.3.1. Passing to other engineers

2.2.1.4. automated test

2.2.1.4.1. especially, for multiple instances of same class

2.2.1.4.2. plugin systems

2.2.1.4.3. Sometimes, it is faster to test a functionality by automated tests than doing it manually

2.2.1.5. Atomic system

2.2.1.5.1. when you write test from small units to large fully integerated one, it becomes extremely easy to find where the code broke very fast

2.2.1.6. catch bugs that are extremely difficult to create manually

2.2.1.7. Performance testing

2.2.1.7.1. Execution time testing

2.2.1.7.2. This is by default, remember openi-ai god object case

2.2.1.8. BTW, it is much easier to test something in debugging environment than actuall environment

2.2.1.8.1. debug is the best, compare to console logs. man without any doubts

2.3. Lesson learned

2.3.1. Static and singelton patterns are horrible for test

2.3.1.1. since they are global previous tests can manipulate the state of the test. and mess each other up

2.3.2. for exceptopns use finally to clear after the fact

2.3.2.1. example

2.3.3. Don't do try catch like this

2.3.4. Read the comments and remove the garabage

2.3.4.1. example

2.3.4.1.1. meaningless note

2.3.5. Nikolay wisdom

2.3.5.1. control type of exception

2.3.5.1.1. var ex = Assert.ThrowsException<Exception>( () => ConfigLocationHelper.MoveConfigFile(nonExistentPath, newPath), "Expected exception was not thrown when moving a non-existent file.");

2.3.5.2. remove comments like this

2.3.5.2.1. /// Covers: Lines 54-57 (ConfigureTraceOnlyLogging branch), Lines 112-120 (reportLoggerSetupException)

2.3.5.3. Parameterized tests: Don't add duplicated parameterized tests that achieve the exact same objective

2.3.5.4. Don't do like this

2.3.5.4.1. if the catch need to fail the test, just let the test fail organically.

2.3.5.4.2. ME: test coverage is a useful metric, but it doesn’t tell the full story.

2.3.6. Gorman wisdom

2.3.6.1. I think coverage for coverage sake is pointless. We want tests that help us avoid regressions.

2.3.6.2. Do not test the test itself

2.3.6.2.1. this had two assert. the first one early in the test, it was testing the setup itself

2.3.6.3. internal visible

2.3.6.3.1. , the internal access modifier allows members to be accessed anywhere within the same assembly, just like public, but only inside that assembly. Internal members are not accessible from outside the assembly.

2.3.6.3.2. for test we can do this

2.3.6.3.3. vid

2.3.6.4. being conservative, by adding asserts to make sure the set up has been done correctly

2.3.6.5. no need to assert samething in multiple way

2.3.6.5.1. example

2.3.6.6. make sure you are testing the business logic and not oher stuff like standard framework

2.3.6.6.1. example

2.3.6.7. remember null and empty string

2.3.7. Dan's wisdom

2.3.7.1. That's a great suggestion from your boss! Re-encoding the decoded bytes and comparing it to the original key would catch additional issues like:

2.3.7.1.1. Incorrect padding

2.3.7.1.2. Extra whitespace or formatting problems

2.3.7.1.3. Non-standard Base64 encoding variations

2.4. AAA Arrange, Act and Assert

2.5. Docker testing

2.5.1. test with docker

2.6. test pyramid

2.6.1. unit testing

2.6.2. integration test

2.6.3. end to end test

2.7. tricks

2.7.1. asnyc

2.7.1.1. test

2.7.1.1.1. solution

2.7.1.2. how to do

2.7.1.3. when you have async calls in your code

2.8. Don't use this pattern

2.9. Supertest

2.9.1. login

2.9.1.1. session/ agent

2.9.1.1.1. Session Persistence

2.9.1.1.2. Simulates Real-World User Sessions

2.9.1.1.3. npm install supertest@latest superagent@latest --save-dev