Test Driving a React.js UI Component with Jasmine
Over the past decade, eXtreme Programming practices like Test-Driven Development (TDD) & Behaviour Driven Developer (BDD), Refactoring, Continuous Integration and Automation have fundamentally changed software development processes and inherently how engineers work. While TDD has seen a great adoption on server side, developers still find it hard to apply TDD for developing UI components.
In this hands-on, live coding demo, Naresh will build a web commenting and discussion feature (like Disqus) in React.js, 100% test driven. He will also demonstrate how TDD will help us drive an object-functional design to strike a pragmatic balance between the Object-Oriented and Functional Programming paradigms.
Outline/Structure of the Demonstration
- Quick intro to TDD (5 mins)
- Live demo of the comment's plugin with the following features (75 mins)
- Should be able to accept comments as json
- Should display more recent comments on top
- Private comments should be displayed only to the author of the comment
- Should take a URL to fetch the comments json from server
- Others should be able to like your comment
- Recap of certain design decisions driven by our tests and how they encouraged functional programming (5 mins)
- Q & A (5 mins)
- How to Test Drive UI code.
- Communication, Simplicity and Flexibility are the hallmarks of a good design. Irrespective of the programming paradigm, TDD can help you achieve these values in your design.
- Deeper understanding of OO and FP design principles.
- Importance of Virtual DOM for UI development.
Developers, Architects & Testers who are interested in Test Driving their UI code. Also Functional Programming enthusiasts
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Naresh Jain - Dark Side of Collaboration
On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.
It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.
In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.
Naresh Jain - MVP Design Hacks
A successful startup/product company needs to master the art of validating early product ideas quickly and effectively. Whether you are building a product, service or a new feature, the two most important questions to find out early are:
- are we solving the right problem?
- if yes, how do we pitch the idea to the target customer to generate a favourable action?
During this session, we'll focus on various safe-fail experimentation techniques used by Lean Startups for quickly identifying and validating the customer's value hypothesis, without having to build the real product. You will leave this session equipped with various MVP design techniques, that will allow you to rapidly discover a viable product/service that delights your customers, without spending a lot of time and effort.
Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best-in-class product/service in that category, launch it, and then pray. Most often, products/services fail, not because they cannot be built or delivered. But because, they lack the market-fitment and customer appeal.
To avoid these risks, these days startups are focusing on building a "Minimum Viable Product" (MVP), a product that includes just enough core features to allow useful feedback from early adopters. This reduces the time to market and allows the company to build subsequent customer-driven versions of the product. Hence mitigating the likelihood of wasting time on features that nobody wants. MVPs are typically deployed to a subset of customers, such as early adopters that are more forgiving, more likely to give valuable feedback.
However the problem with MVPs is that companies still spend too much time building stuff and very little time learning. Don't forget the purpose of MVP is validated learning NOT building. This session will give you ideas on how to quickly formulate and test your value and growth hypothesis in a scientific framework using extremely cheap MVP techniques collectively referred to as MVP Design Hacks.
Rajat Talwar - Pains and Gains of being a Full Stack DeveloperRajat TalwarFull Stack Dev at confengine.com / Co-founder poolmyride.comXNSIO
schedule 3 years agoSold Out!
As the industry is shifting towards an Agile (Continuous Delivery) style for developing products and services, (whether startups or large established organisation), everyone today has to thrive by innovating and adapting to the latest trends in technology. They have to keep themselves ahead in the race to delight customers. Full stack developers are key players in experimenting and delivering value consistently using varied tools and technologies throughout the stack.
In this session I'll be share my journey of how I became a full-stack developer. Hopefully this will help others understand how they can target and plan to gradually become a full stack developer in their respective teams.
Also I'll highlight the following topics:
- What is the importance of a full stack dev?
- What tools/resources/languages in my experience work best for full stack developers?
- Downsides of being a full stack developer!
Naresh Jain - The Decline and Fall of Agile - Antifragile Mindset to Rescue
What started off as a trial-and-error approach to improve the state of software development by a bunch of tinkerers, is today dominated by management consultants, "Thou-Shall" codified frameworks and rigid, expensive tools. Over the last 20 years, we've gone from, "I'm not sure, let's try this in a small-safe environment" to "you/your-team sucks; you guys have a very poor agile maturity because you are not doing _x_y_z_ (not conforming to the standards)." Along the way, we've lost the purpose of being agile .i.e. to embrace uncertainty and simplicity. Instead we've been forced to believe that consistency via top-down standardisation and predictability by increasing the rigour on process is our eternal quest. Anything that sounds simple and works 80% of the cases is discarded as being naive. What once drove thought-leader into agile, is now driving them insane. This is the unfortunate fate of Agile.
Luckily there has been some fresh perspectives from Nassim Taleb, author of Antifragile. His work explains how some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. More importantly why antifragility is beyond resilience or robustness.
In this talk, I'll use some of Nassim's thoughts (and some of my own) to explain what is wrong with our current approach to Agile and how we can bring life back into Agile. Particularly how we can leverage Volatility, Uncertainty, Complexity, and Ambiguity to make product development more antifragile.