Tremor – The React library to build dashboards fast
tremor.so
tremor.so
If it wasn't for my test suite, things would have been a giant mess long ago and I probably would have abandoned it. I can't think of doing a react project without a test suite because over time, any dependencies you have (including on react) will end up breaking things in ways that you don't know. Without those tests, you can't be sure of upgrades... which you're forced to do because your users will want to do things like upgrade react.
So... any project like this... in order for me to ever add it to my own project or depend on it in any way, really needs a test suite.
The test suite for this project is pretty much non-existent, which is a huge bummer should should be a huge red flag for anyone who thinks about using it. You're just going to end up with broken code.
You're right on the point of using another low code solution though... it still opens you up to dependency issues. You might also want this as a product with its own skinned UX/UI that you have full control over. Third party 'commercial' products won't always give that to you.
`@testing-library/react` and jest to run it. snapshots and a bunch of action code too.
There are more modern frameworks now too that can be used for integration tests, but I haven't bothered yet as the snapshots have almost always caught the issue.
It boggles my mind that react.dev doesn't start off teaching, with writing tests.
My dependency is on MUI, which is a massively used common shared component library. If MUI changes, and it breaks my snapshots, I'd absolutely want to know about it.
Currently figuring out a strategy for introducing testing into an already large codebase and being very cautious of snapshot tests because of this. Experimenting with visual regression testing but early indicators suggest it could get very expensive if we're not careful about what is covered.
Visual diffing, cypress >>>> snapshots IMO.
Agreed that cypress today is probably a better solution.
The components I test all use classes, so there aren't embedded styles. Occasionally the generated class names change across different versions, but it is a small price to pay and easy enough to just update the shots.
I'd also argue that I'd want that snapshot to fail. I'd want to know why someone made that change, especially if they were going in the other direction... f00 -> ff0000.
Are they useful and do they prevent bugs is the better question
You haven't written one yourself? Is your theory that since you can't write one, they aren't possible?
All my tests are good enough to ensure that if I upgrade a library or change underlying functionality, something breaks if the output is not expected. That is my primary concern and that is what I test for.
That's exactly the kind of test double I'm talking about
You can read the history here: https://github.com/lookfirst/mui-rff/issues/455
If you're working with people who randomly 'forget' things while they are doing development, then I guarantee that you're working with people who also write buggy code. In fact, in this case, it was ME who wrote that buggy code. I own it. Not all code gets 100% coverage and sometimes things get missed. That is ok. What is not ok is skipping tests because you might forget something and therefore think it isn't worth writing tests at all.
I consider buggy code the act of developers writing the code at least 2x instead of 1x. If you or your company is paying someone $X a year to write code once and they are actually writing code more than once, then I would highly suggest you look for new people to work with because that is a terrible return on investment.
If your developers are writing tests, along with their code, then the code is far more likely to be correct and better thought out and less buggy than code that was just hand tested as they developed it. Speaking of that 2x example, I'd rather pay someone 2x the amount of time to write code, with tests, than the other way around.
We all write bugs, we're human and it's hard to think of everything all of the time.
My point was, when we make a thinking error that causes us to write a bug, that same thinking error means we also don't write that test that could find it. If you had thought of writing a test for the disabled thing when you wrote the code, you also would have written it correctly because you would have had that case in mind then.
Now you have a test, but because someone reported the bug and you fixed it. Now it's almost certainly not useful to have anymore.
I believe in automated tests, but for tricky logic mostly.
Humans can't think of everything all the time - TDD guides you to think about one thing at a time.
No one is sitting there adding a disabled prop on their component that then disables an input for no reason. You had intent when writing it. It's possible that a co-worker distracted you, or you went for a break, or you went down another rabbit hole, and ended up skipping disabling the input based on the prop.
If you're practicing TDD, you would have written a failing test before creating the disabled prop. That test will continue to fail until the productive code has been written. It helps to protect against those thinking errors in the first place.
There is almost no way to even know what features they have, especially over time. Imagine that MUI added disabled in a new release and now my project isn't implementing it during an upgrade. TDD wouldn't have caught that.
But for components, that call some of those hooks and then render some JSX, I've never been able to write a test that found a bug later on. Every single time one of them failed, either the change made was so large that the whole build failed to compile anyway, or it was because there was new desired behaviour and the test needed changing, not the code.
If a type of test doesn't help find bugs, it's a waste of space.
If the desired behavior is changing, then the test should fail and yes, you need to rewrite it. That's how testing works.
Some are simple (although very few are as simple as your example) and some are complex, depending on the portion of the app being tested. Some are basically integration tests for components/widgets, where it runs it in isolation to test the inputs and outputs. Others are more like traditional unit tests where it's purely testing business logic, API and model interactions (mocked), form validation logic, etc.
Unless you're talking about very simple client apps, there's always stuff that can be tested that will provide significant business value by preventing bugs and broken code from getting to end users
- Visit a lesson page with a code example that returns a string.
- Enter the correct answer to that code example, but without the quotes around it.
- Assert that the text "Almost, but the answer is a string so it needs quotes." now exists on the page.
(To make sure that we know when actual rendered pixels change unexpectedly, we use Percy, which is a separate topic.)
We use ui tests specifically for testing accessibility, analytics and data passed along during navigation.
We use fixtures for all of this.
None of these tests really help with bugs. What they do help with is:
- Making sure the ui stays really decoupled from the business logic. This helps a lot with getting the data unit tested which does help a lot with bugs.
- Making sure that analytics and accessibility are not forgotten about. This helps a ton when refactoring.
- Making the intent of the code really clear during review.
It takes a bit of practice and being ruthless about removing/fixing stuff that’s not helping. I have found it makes it much easier for new developers to work, review code and understand how the code is organized. YMMV.
Some examples:
- At the API layer, it mocks the network layer and tests that, when triggered, it sends the correct request and given a response, handles it correctly (both for success and fail responses, as well as different expected data).
- business logic layer is some of the most important tests, this layer will test things like how data flows through the app and how it might be transformed along the way for use in the UI. This layer generally sits between the API and UI, so it mocks functions in the API stack and tests various responses, tests streams of data. This layer often is your "traditional unit tests" - testing individual functions to ensure they are idempotent, no (unintended) side effects creep into the code, putting in X gets back Y, etc.
- Higher order UI components - these are components that, while they may have some UI (yah, I know, not purely higher order), they are generally the component that acts as an intermediary between the business logic and more pure UI (display) components. The tests here would mock any calls into the business logic, make sure it properly requests the needed data and then check to see that any local logic is correct. This layer may be handling route params or query params, and adjusting the data request based on that or other data stored in memory or in the app. It may be handling collection of form data and giving it to a business logic function, and handling any errors that may send back, and the tests will check that. It often has functions that are triggered by actions in display components, and rather than try to wire components together in tests (we do have some e2e tests that check at that level), it's better to test those functions in isolation at this layer.
- Display UI components - I don't want to assume, but based on the comments, this is likely what you have thought of when you think of UI testing. At this layer, there should be much less logic in each component. It usually has data inputs, and then renders that into a template. We don't "test the framework" - there's no sense testing that an input prop is "set" correctly. But if the UI component does anything with that prop to prepare it for display, we'll test that. Or if it has UI actions - this is one place we will sometimes tie to the DOM and test things like click events, but most of the time that isn't really necessary (again, we make as assumption that if we properly wire up a click handler, it will fire on click). So many times we will just test the handler themselves, if they do any logic prior to emitting that value back out to a higher order component or to the business logic layer. We try to keep these simple, but there are sometimes tests here that are testing that expected DOM elements are visible based on the state of input data, or that the expect text is visible based on user action (i.e. did a panel display text when the user clicked it open). This is the layer we have to be fairly careful not to write "lazy" tests (did the framework render the text assigned to a variable and interpolated in the template isn't super valuable).
If it matters (and I don't think it should, because the practice of writing good tests, even for client apps, isn't specific to language/framework) our primary apps right now are written in Flutter and Angular. We also use or have used Swift and Kotlin (iOS/Android respectively), Java, React (little bit of React Native but quickly abandoned in favor of Flutter), and Ember (had a pretty big test suite for an Ember app, since shut down though). And, despite all of the above, most of our logic does not actually reside on the client side but rather lives in the API/backend and we are mindful to try to keep as much logic there as possible. And we have good test coverage there as well. Of course, for all our code, the coverage could always be better.
Anyways, I can't really pull code samples as the apps are proprietary (and this is getting long enough as it is), but I hope that answers your question and helps illustrate at least why I believe there can be significant value in client side tests.
You can check:
https://youtu.be/BQqzfHQkREo https://youtu.be/OVNjsIto9xM&t=28m06s https://youtu.be/VvLocgtCQnY
The nature of a personal project is such that I may not come back to it for months, sometimes even years. The first thing I always do is run the test suite. It's my lodestar. It helps me understand what state the project is in so I can confidently pick up where I had left it.
It is also my requirements documentation - as code.
I'd rather dole out incomplete MVP's with tests and fewer features than to skip tests entirely just to hit crazy timelines with a buggy product. Experience says this almost always has positive long term results.
Then it happens again. And again...
Eventually you're left pulling in this huge library with 2MB of CSS just for the four components you're still using from it. Then a new dev joins the team and gets to enjoy the confusion of "should i use $library component here? Or do we have another wrapper for it? or is there something else entirely being used for it?".
Just avoid the hassle and stick with a curated list of well fleshed out individual components that are tested and have thousands of stars each. Create a barebones wrapper over it to match your design system, and call it a day.
While component libs like this can be used for consumer-facing UI, when we talk about "dashboards" it's also often backoffice admin panels.
You shouldn't be reaching for hand-writing UI design & logic in that scenario. You should be looking for an admin panel interface tool. Laravel has these in spades: Nova, Backpack, and Filament are the big three. You write some code and some logic tied to it, and the tool creates the UI for you. This lets you get back to writing code for the actual customers instead of for business processes.
These can be used for consumer facing panels too, but with less control over the design, they're not really intended for it.
But the JS ecosystem insists on being fragmented, so everything is rewritten manually.
"Batteries included" needs a lot more than just batteries (the UI components).
The server is a very simple node/express app and the front end is written in vanilla javascript. I also use GitHub's primer css (https://github.com/primer/css) and a heavily stripped down version of tabler's css (https://github.com/tabler/tabler)
Note, DevBoard is more geared towards hackers, so Tremor's is probably a much better fit if you are looking for an out of the box solution.
* Ant design pro (https://github.com/ant-design/ant-design-pro/) * Material Dashboard React (https://github.com/creativetimofficial/material-dashboard-re...) * Volt React (https://github.com/themesberg/volt-react-dashboard)
Anyone have more suggestions?
Then when I came back to the home page and searched for "license", I confirmed it says "Apache-2.0 license" in light-grey, small font in the middle of the page.
Feature request: I wish the table supported basic sorting and maybe even filtering out of the box, I find these useful in the dashboard context. Perhaps I’m not seeing it, or maybe there’s a way to add this easily?