Shipping React app with zero-bugs policy using TDD (Nik Sumeiko)

[@TechExcellence]

Here's a link to the repository of the demo project: github.com/niksumeiko/iban-validator-react-tdd-kata

[@jcupac]

Very practical code demo that simplifies TDD implementation

[@TechExcellence]

Thank you!

[@thatkidplongy]

More of this type of content please, very helpful!

[@TechExcellence]

Thanks for your feedback, what did you find most helpful in the video?

[@aleksamitic6655]

Amazing stuff! Deff going to try this practice.

[@TechExcellence]

Thank you @aleksamitic6655for your feedback :)

[@marlonsaviandev]

Awesome content

[@TechExcellence]

Thank you, we appreciate your feedback!

[@vladanulardzic3186]

Thank you TE and Nik Sumeiko . GREAT job, really. Practice with theory backup. Explained in details - STEP BY STEP. Covered all by somebody who works in bank. If possibly - keep on with other projects.

[@TechExcellence]

You're welcome Vladan!

[@sepehrsafarii]

Awesome! Thanks for the content.

[@TechExcellence]

You're welcome, glad that you enjoyed it!

[@nicolasdiot7007]

Hi, what is the name of the app you used to run your e2e test and have a live demo (at 36:06 on the video) ? And thank you a lot for this code demo, it really simplifies TDD implementation ! 😊

[@niksumeiko]

We use Cypress for both E2E and integration tests.

[@nicolasdiot7007]

Thank you

[@PaulSebastianM]

23:44 I find the IBAN validation API adapter a bit too complicated. You shouldn't need a closure to cache the IBAN to be validated. You could just create an Adapter class or object that would contain IBAN related functions like validating an IBAN, extracting encoded information from that IBAN and so on. This would mean less mallocs to just validate an IBAN. Just have a singleton adapter and functions you can directly call on it, like `validateIBAN(iban: string)`.

[@niksumeiko]

The closure leaves an opportunity to pass an argument when the adapter is for mutations: // Adapter factory function createAdapter(options) { ‎ ‎ return (x) => { ‎ ‎ ‎ ‎ // do communicate with an outside world ‎ ‎ }; } // Use Case const useCreateTodo = () => { ‎ ‎ const factory = useAdapterFactory(); ‎ ‎ const mutation = useMutation({ mutationFn: factory() }); ‎ ‎ const [formValues, setFormValues] = useState(); ‎ ‎ const handleSubmit = () => { ‎ ‎ ‎ ‎ const result = await mutation.mutate(formValues); ‎ ‎ }; };

[@niksumeiko]

Plus, the closure allows passing the request (a method that communicates to the outside world). This makes it easy to write a unit test for such an adapter because a fake request can be provided.

[@PaulSebastianM]

I hope you end up using Mock Service Worker instead of mocking window.fetch... will have to watch to the end and see, because I don't like having to dirty the API adapter by injecting what is basically an http client. It might make sense in C# but in JS world you have things like window.fetch or axios and their interfaces are not compatible, unless you abstract them yourself and create a common interface.

[@niksumeiko]

If we mock the request (a method that communicates to the outside world) using MSW, the test will run a bit slower than if we pass a fake implementation of the request. Doing MSW in the integration tests - where we assert user journeys by rendering specific parts of the app - totally makes sense. However, asserting all the implementation details of the adapter (e.g., headers that are passed into the request) by involving MSW in the unit test is inefficient, nor it's efficient to assert these implementation details in integration tests. A better approach is to have a trivial unit test doing this job.