Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
I did not find a tutorial when I first learned JS testing...I pre tended I knew what I was doing and frantically figured it out one weekend! I was building the most complex UI components I have ever dealt with (it was the interface to customize sandwiches when ordering online from as restaurant) and ended up with 2000 lines of KnockoutJS because I failed to convince my manager that React was a smart choice.
2000 lines of code is hard enough to keep track of on its own. I essentially used a Redux-like system via custom message passing to make the component work, and it was so difficult trying to trace the execution flow through all that code. I knew I needed some tests so I could prove that at least some of it worked correctly!
I began adapting functional programming principles through Lodash and I was starting to clean things up enough that I had pure functions (no side effects, deterministic input) ready to test. I couldn't figure out Webpack (still struggle to this day to do so!) and my tooling knowledge was pretty weak, so I chose QUnit because it seemed easiest.
It was not a pretty experience, but it taught me a lot having to figure out how to set up all these components myself and add it to my Gulpfile and teach the rest of the team how to test if they wanted to. Sometimes you have to let life be tutorial!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I did not find a tutorial when I first learned JS testing...I pre tended I knew what I was doing and frantically figured it out one weekend! I was building the most complex UI components I have ever dealt with (it was the interface to customize sandwiches when ordering online from as restaurant) and ended up with 2000 lines of KnockoutJS because I failed to convince my manager that React was a smart choice.
2000 lines of code is hard enough to keep track of on its own. I essentially used a Redux-like system via custom message passing to make the component work, and it was so difficult trying to trace the execution flow through all that code. I knew I needed some tests so I could prove that at least some of it worked correctly!
I began adapting functional programming principles through Lodash and I was starting to clean things up enough that I had pure functions (no side effects, deterministic input) ready to test. I couldn't figure out Webpack (still struggle to this day to do so!) and my tooling knowledge was pretty weak, so I chose QUnit because it seemed easiest.
It was not a pretty experience, but it taught me a lot having to figure out how to set up all these components myself and add it to my Gulpfile and teach the rest of the team how to test if they wanted to. Sometimes you have to let life be tutorial!