CodeGenX VS Enzyme

GitHub link: https://github.com/DeepGenX/CodeGenX

Looks good, I am currently working on a similar open-source project called CodeGenX. Its a fine-tuned version of GPT-J. Can I ask how long this took to train, and what hardware was used?

Hey Everyone!

We are delighted to announce the first version of CodeGenX. CodeGenX is a free and open-source code-generation system (similiar to Github Copilot) powered by a fine-tuned version of GPT-J.

You can find details for installation and instruction on usage here: https://docs.deepgenx.com. Our GitHub repository can be found here: https://github.com/DeepGenX/CodeGenX.

I think it is important to identify what CodeGenX can and cannot do, so we know what to expect. We have found that CodeGenX works well for common use cases which occur repeatedly in the training set. It understands context and outputs code with similar formatting to your previous code using the appropriate variables. But it does not shine in places where logical or mathematical computations are needed. This does not mean that it doesn't understand any logic or math, but just a weak point of the model.

Here are some links that have additional information:

Website: https://deepgenx.com

CodeGenX is an extension that will help you write your code better and faster, it uses a fine-tuned version of GPT-J to generate code that's readable and efficient. You can find more details and a guide on how to use CodeGenX on our website, if you're interested in the source code, you can take a look at the github repo. If you have any questions or feedback, you can contact us via discord or by replying to this post.

You can find details for installation and instruction on usage here: https://docs.deepgenx.com. Our GitHub repository can be found here: https://github.com/DeepGenX/CodeGenX.

Hope you're doing well. We (a group of volunteers) are currently working on an open-source project called CodeGenX. The project is a code generation extension for VS Code (similar to GitHub Copilot) based on a custom fine-tuned version of GPT-J. The problem is that most of us working on the project are Machine Learning Engineers/Data Scientists and do not have much experience in webdev.

Probably Enzyme was the first to popularize component testing in React by doing shallow rendering and expecting some things to be there in the React component tree. Then React Testing library came and took component testing to a whole new level.

Enzyme is another popular testing utility for React. It allows you to manipulate and traverse React components' output, making it easier to write comprehensive tests.

ljharb is an extremely interesting person. There’s no doubting the positive impact he’s had on the OSS community and the work he’s done.

However, there are some things he does that are incomprehensible.

For example, Enzyme. Over three years ago this issue was opened for Enzyme on React 17: https://github.com/enzymejs/enzyme/issues/2429

Nothing moved for a while, and I think he said something along the lines of “if you want React 17 support, stop complaining and help”. So the community got involved. There are multiple PRs adding React 17 support. Many unofficial React 17 adapters. A lot of people have put a lot of work into this, ensuring compatibility, coverage etc. Yet to this day, none of them have been merged. Eg https://github.com/enzymejs/enzyme/pull/2564

Given the amount of time that has passed, and the work the community has put in, something is amiss. It feels like he’s now intentionally avoiding React 17+ support. But why? I don’t understand why someone would ask for help then ignore the help when it comes in. That isn’t much better than the swathe of rude/entitled comments he was getting on the issue before he locked it.

I ended up migrating to RTL, but this made many of my tests more complicated (especially compared to shallow rendering).

Enzyme Documentation

One way to do this is by writing tests for your React components. Tools like Jest and Enzyme make it easy to test your component's behavior, rendering output, and state changes. By writing tests for your components, you can ensure that they behave as expected and prevent issues before they reach production.

GitHub link: https://github.com/enzymejs/enzyme

So If you have experience with enzyme testing, where you might be checking the value of state once you click any button or you might be checking the prop value If something changes.

Enzyme offers two types of API for shallow rendering and full rendering. Both are preferred for different test scenarios and functionalities.

At Visa, I was writing unit tests for a Next.js project using components designed with Chakra UI. That's where React Testing Library came in handy. Unlike other solutions like Enzyme, I did not have to worry about the application snapshot but could instead focus on each UI element, its expected behaviour and the data it would render upon user interactions.

Superset uses Jest and React Testing Library (RTL) to write unit and integration tests. In the past we used Enzyme, but now that we're currently converting all of our class components to functional components, Enzyme cannot support our testing needs. Since RTL is better for testing functional components, we're converting all of our test files to RTL. This can be quite a learning curve - I've gone through a lot of the process so I'd like to share what I've learned so far.