DEV Community: David Rueda

I Hated Writing Tickets (Until I Used AI)

David Rueda — Fri, 20 Feb 2026 09:07:42 +0000

🗣️ I hate creating tickets. I don’t know what value it provides to write an extensive explanation. I know what needs to be done, so I feel I’m losing valuable development time by spending so much time noting down all the little details.

Does this sound familiar? At some point, if you have worked as a software developer, ticket creation has been one of the main discussion topics in refinement sessions and retros. Many of us tend to think descriptive tickets are a waste of time. With simpler versions we could do what tickets are supposed to be for. Organizing work.

But… What are the downsides of simpler tickets? Let’s list some:

Harder collaboration: what happens if your colleague opens a ticket, but you are in charge of implementing it? What happens if you don’t have the context in which that ticket was created?
Traceability: What decisions have been made?
Diffuse Definition of Done (DoD): Are you sure the acceptance criteria for that ticket is actually met? Are you missing something?
Provided value: Is the ticket actually valuable to the user? Will it improve its experience?

I’m sure all of you would be able to list some more disadvantages with ease. However, we need to find a balance between the ticket description and the time spent to create it. Nowadays, AI is an almost indispensable tool that is integrated in all of our workflows. And ticket creation should not be the exception.

The good news? You can write better tickets with AI without sacrificing speed or context. Modern dictation tools bridge the gap between quick note-taking and comprehensive documentation.

📝 Creating tickets with Superwhisper

AI-powered dictation helps development teams write better tickets with AI by capturing spoken context, structuring it automatically, and standardizing formats across the backlog.

Superwhisper is a “ultra-fast AI powered dictation that understands what you want to say and how you want to say it.”. It is able to translate your ideas in pre-built formats (such as formal emails or messages) or custom formats (we’ll address those in this article) that can be defined by a series of rules and applied in whatever applications you may need.

And how does this apply to ticket creation? With some creativity, you’ll be easily able to transform functionality ideas or business requirements in detailed tickets in seconds!

Setting up Superwhisper

Download Superwhisper from its homepage. It supports Windows, MacOS and iOS.
Go to Modes. In this tab, you’ll be able to define custom or pre-built modes, and what applications and even pages these modes will be applied to.

Create a new mode by clicking on the ‘Create mode’ button and selecting ‘Custom’.

Define your rules. This is the prompt I’ve been using so far, which has worked great. Feel free to modify it to meet your team or personal needs!

You are a Senior Product Owner.

I will describe a software requirement in Spanish. // Add here your mother tongue! 
Your task is to:
1. Understand the requirement.
2. Translate it into clear English.
3. Rewrite it as a backlog ticket using the exact template below.

Rules:
- Use a clear USER TYPE.
- Acceptance criteria must be written as simple bullet points, not Gherkin.
- Each criterion must be testable and explicit.
- Do not invent requirements.

Template:

> [!IMPORTANT]
> _AS A_ `<USER TYPE>`
> _I WANT TO_ <user goal>
> _SO THAT_ <business value>

### Acceptance Criteria

- ...
- ...
- ...

### Technical Approach (optional)

- ...

Define when you want to apply these rules. E.g. If you use Brave browser and your ticket platform is Github, you can easily define that in the advanced settings:

🧪 Demo time!

Imagine you are working on a SaaS application that displays information about the documents you uploaded, in a table format. Right now, the Due Date field is
displayed, and it's taking a lot of the table space when it's not needed immediately. You want to create a ticket to remove it.

You use your shortcut to open Superwhisper.
You say: **"I don't want the users to see the due date in the documents table"
Superwhisper returns the following:

> [!IMPORTANT]
> _AS A_ `End user`
> _I WANT TO_ not see the expiration date column in the documents table
> _SO THAT_ the documents listing does not display expiry dates to users

### Acceptance Criteria

- The documents table in the UI no longer displays a column labeled "Expiration Date", "Expiry Date", "Due date" or similar.
- No expiration date value is visible in any row of the documents table for any document.
- Removing the column does not remove or alter other columns or data in the documents table.
- The table header layout adjusts correctly (no empty column gap) and aligns with remaining columns on desktop and mobile
  breakpoints supported by the product.
- Sorting, filtering and pagination on the documents table continue to function as before for the remaining columns.
- If there is a details/preview panel accessible from the table, it still shows the expiration date if that is a separate
  requirement; otherwise state if expiration date should also be hidden there (no change required per this ticket).
- Changes are covered by a UI visual check and an automated end-to-end test that asserts the expiration date column is not present.

### Technical Approach (optional)

- Remove or hide the expiration date column from the table component and any table column configuration.
- Update table CSS/layout to remove gap and ensure responsive behavior across supported viewports.
- Update frontend tests and add an end-to-end assertion to confirm column absence.
- Ensure backend APIs still return expiration date (if needed elsewhere); do not modify API unless required by product decisions.

Voilà ✨! You’ve created your refined ticket!

If you've struggled with ticket quality or time spent on documentation, learning to write better tickets with AI offers a practical solution. Tools like Superwhisper transform the process from a productivity tax into a lightweight investment in team clarity.

Ticket writing doesn’t have to be a productivity tax. With the right tooling and a bit of automation, it becomes a lightweight investment in clarity, collaboration, and long-term velocity. If AI can help us spend less time documenting and more time building, that’s not overhead—that’s leverage.

The 5 principles of Unit Testing

David Rueda — Thu, 14 Sep 2023 14:14:43 +0000

Get your software development to the next level with these 5 powerful principles of unit testing! Testing your code is one of the most important aspects of software development, as it ensures quality, scalability, and reliability of your product.

But, without any guidelines, it can be difficult to write effective tests. In fact, testing code can become more complex and harder to maintain than the actual production code!

Don't let this happen to you. Follow these best practices for unit testing, which can be applied to any framework or library, both in the backend or frontend of your application, and you'll be able to write lean, accurate, and easy-to-read testing code. With these, you'll save valuable dev time, avoid technical debt, and enjoy testing your code:

1. Lean and accurate testing

Testing code must be simple and easy to work with. Anyone looking at the test should know instantly what the test is about and what its purpose is. Developing tests should bring great value with very little effort and time investment.

Do you need more than 30 seconds to read and understand your test? Rewrite it!

Testing just for ‘coverage percentage’? Don’t!!! This just makes the majority of the test suite to be unnecessary and undesirable for the developers. Test only what’s needed. It’s better to drop some tests for agility and simplicity, testing only the main business logic and principal edge cases.

2. Test the behaviour, not the implementation

Don’t check every single line and internal variable changed in the code. When testing, you should focus on the result. The result should always remain the same even if the code inside the method is refactored!

This way, you won’t need to rewrite your tests if the code base is changed.

// Wrong ❌ - Test behaviour
describe('Evaluation Service', () => {
  describe('Register Students', () => {
    it('Should add new students to the evaluation service', () => {
      const studentJosh = {
        id: 1,
        name: 'Josh McLovin',
        average: 6.98,
      }
      evaluationService.addStudent(studentJosh)

      expect(evaluationService._students[0].name).toBe('Josh')
      expect(evaluationService._students[0].average).toBe(6.98)
    })
  })
})

// Right ✅ - Test behaviour
describe('Evaluation Service', () => {
  describe('Register Students', () => {
    it('Should add new students to the evaluation service', () => {
      const studentJosh = {
        id: 1,
        name: 'Josh McLovin',
        average: 6.98,
      }

      evaluationService.addStudent(studentJosh)
      expect(evaluationService.getStudentAverage('Josh')).toBe(6.98)
    })
  })
})

3. Test naming and structuring. AAA pattern.

Have you ever had a failing test named ‘it should [...] correctly’ and lost a couple of minutes finding where the problem was?

Naming and structuring your test suite can enhance your ability to address any failing tests swiftly and accurately, ultimately saving you valuable time. So, let's dive into two key principles to keep in mind for your next testing endeavours:

3.1 Thoughtful test naming:

When naming your tests, attempt to incorporate the following information:

- What is being tested?
- Under what circumstances?
- What is the expected outcome?

// Right ✅ - Test naming

// 1. What is being tested:
describe('Evaluation Service', () => {
  describe('Evaluate Students', () => {
    // 2 & 3. Context and expected result
    it('If the student grade is below the minimum grade, student should be suspended', () => {
      const students = [
        { name: 'Mark', grade: 4.25 },
        { name: 'Colin', grade: 6.7 },
        { name: 'Ben', grade: 5.3 },
      ]

      const result = evaluationService.evaluateStudents({ students, minGrade: 5 })

      expect(result['Mark']).toBe('suspended')
    })
  })
})

3.2 The AAA pattern for testing code structure:

If you want to maintain a readable and easily comprehensible test suite, structure the test as it follows:

Arrange: set up all the code needed to simulate the required situation. This can include initialising variables, mocking responses, instantiating the unit under test, etc.
Act: execute what is being tested, usually in a single line of code.
Assert: check the obtained result is the expected one. Like the one above, this should take only one line.

// Right - AAA Testing Pattern
describe('Evaluation Service', () => {
  describe('Average Calculation', () => {
    it('Should calculate the average grade of all the students', () => {
      // Arrange: create an object with the student names and their grades
      const students = [
        { name: 'Mark', grade: 4 },
        { name: 'Colin', grade: 10 },
        { name: 'Ben', grade: 7 },
        { name: 'Tim', grade: 3 },
      ]

      // Act: execute the getAverage method
      const avg = evaluationService.getAverage(students)

      // Assert: check if the result is the expected one -> (4+10+7+3)/4 = 6
      expect(avg).toEqual(6)
    })
  })
})

4. Deterministic and isolated tests

If a single failing test turns your entire suite red, then you may not be approaching it in the right way!

Tests should be independent and isolated, targeting and dealing with one specific logic at a time, accomplishing a faster and more stable test suite.

What happens if you don’t write your tests independently?

You won’t be able to pinpoint the exact cause and location of the bugs and issues.
When refactoring the tests, you will have to update and synchronise multiple ones.
You won’t be able to run your tests in any order, which may cause breaking or skipping some of the assertions or expectations.

5. Property-based testing and realistic data

Tired of writing a large amount of possible inputs in your tests? Property-based testing does it for you! But… What 's that?

Property-based testing creates hundreds of possible combinations, stressing the test and increasing the opportunity of uncovering previously unnoticed bugs. This approach can even return the inputs which may have caused an unexpected outcome.

Libraries like JSVerify or Fast-Check offer essential tools to facilitate property-based testing.

However, if you prefer not to dig into such extensive testing, it is crucial to utilize realistic data whenever possible. Inputs like 'abc' or '1234' might erroneously pass the test when it should actually fail.

// Wrong ❌ - False Positive - Test that passes even though it shouldn't 
class EvaluationService {
  _students =  [];

  addStudent(student) {
    // Add the student if the name has no numbers
    if(!student.name.matches(/^([^0-9]*)$/)){
      this._students.push(student);
    }
  }
}

describe('Evaluation Service', () => {
  describe('Register Students', () => {
    it('Should add students to the Evaluation service', () => {
      const mockStudent = {
        id: 2,
        name: 'username',
        average: 7
      }
      // Won't fail because the name is a string without number -> We are not checking what happens if the user
      // inputs a name with a number.
      evaluationService.addStudent(mockStudent) 
      expect(evaluationService.getStudentAverage('username')).toBe(7)
    })
  })
})
// In the example above, we are making a test so the test passes, instead of looking for edge cases with realistic data

Bonus Tip!

If you are getting a hard time testing any logic in your component, this could reflect that, maybe, you should break your component logic into smaller, easier and testable pieces of code!

In conclusion, following this best practices may lead to a new, readable and maintainable way of testing your beloved production code. Thanks for reading!

A tested app is a reliable app!